aboutsummaryrefslogtreecommitdiff
path: root/src/backend/access/gist
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2017-08-19 13:39:37 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2017-08-19 13:39:52 -0400
commit1c3869c0bea4376bcbb358e1abf5ed95e8c41865 (patch)
tree4783897cd3c02e3d45d4229991a07b93d5a2938a /src/backend/access/gist
parent7c84acc455368721e046dc0cc2eb84d62c4f5e61 (diff)
downloadpostgresql-1c3869c0bea4376bcbb358e1abf5ed95e8c41865.tar.gz
postgresql-1c3869c0bea4376bcbb358e1abf5ed95e8c41865.zip
Fix possible core dump in parallel restore when using a TOC list.
Commit 3eb9a5e7c unintentionally introduced an ordering dependency into restore_toc_entries_prefork(). The existing coding of reduce_dependencies() contains a check to skip moving a TOC entry to the ready_list if it wasn't initially in the pending_list. This used to suffice to prevent reduce_dependencies() from trying to move anything into the ready_list during restore_toc_entries_prefork(), because the pending_list stayed empty throughout that phase; but it no longer does. The problem doesn't manifest unless the TOC has been reordered by SortTocFromFile, which is how I missed it in testing. To fix, just add a test for ready_list == NULL, converting the call with NULL from a poor man's sanity check into an explicit command not to touch TOC items' list membership. Clarify some of the comments around this; in particular, note the primary purpose of the check for pending_list membership, which is to ensure that we can't try to restore the same item twice, in case a TOC list forces it to be restored before its dependency count goes to zero. Per report from Fabrízio de Royes Mello. Back-patch to 9.3, like the previous commit. Discussion: https://postgr.es/m/CAFcNs+pjuv0JL_x4+=71TPUPjdLHOXA4YfT32myj_OrrZb4ohA@mail.gmail.com
Diffstat (limited to 'src/backend/access/gist')
0 files changed, 0 insertions, 0 deletions