RestorePendingSyncs-at-RestoreRelationMap-v1.patch

text/plain

Filename: RestorePendingSyncs-at-RestoreRelationMap-v1.patch
Type: text/plain
Part: 0
Message: Re: BUG #18545: \dt breaks transaction, calling error when executed in SET SESSION AUTHORIZATION

Patch

Same data as JSON: GET /api/v1/attachments/:id/patch the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes. API reference →
Format: unified
Series: patch v1
File+
src/backend/access/transam/parallel.c 7 11
Author:     Noah Misch <noah@leadboat.com>
Commit:     Noah Misch <noah@leadboat.com>

    Fix parallel worker tracking of new catalog relfilenumbers.
    
    Reunite RestorePendingSyncs() with RestoreRelationMap().  If
    RelationInitPhysicalAddr() ran after RestoreRelationMap() but before
    RestorePendingSyncs(), the relcache entry could cause RelationNeedsWAL()
    to return true erroneously.  Trouble required commands of the current
    transaction to include REINDEX or CLUSTER of a system catalog.  The
    parallel leader correctly derived RelationNeedsWAL()==false from the new
    relfilenumber, but the worker saw RelationNeedsWAL()==true.  Worker
    MarkBufferDirtyHint() then wrote unwanted WAL.  Recovery of that
    unwanted WAL could lose tuples like the system could before commit
    c6b92041d38512a4176ed76ad06f713d2e6c01a8 introduced this tracking.
    RestorePendingSyncs() and RestoreRelationMap() were adjacent till commit
    126ec0bc76d044d3a9eb86538b61242bf7da6db4, so no back-patch for now.
    
    Reviewed by FIXME.
    
    Discussion: https://postgr.es/m/FIXME

diff --git a/src/backend/access/transam/parallel.c b/src/backend/access/transam/parallel.c
index d4e84aa..4a2e352 100644
--- a/src/backend/access/transam/parallel.c
+++ b/src/backend/access/transam/parallel.c
@@ -1421,17 +1421,18 @@ ParallelWorkerMain(Datum main_arg)
 	StartParallelWorkerTransaction(tstatespace);
 
 	/*
-	 * Restore relmapper and reindex state early, since these affect catalog
-	 * access.  Ideally we'd do this even before calling InitPostgres, but
-	 * that has order-of-initialization problems, and also the relmapper would
-	 * get confused during the CommitTransactionCommand call above.
+	 * Restore state that affects catalog access.  Ideally we'd do this even
+	 * before calling InitPostgres, but that has order-of-initialization
+	 * problems, and also the relmapper would get confused during the
+	 * CommitTransactionCommand call above.
 	 */
+	pendingsyncsspace = shm_toc_lookup(toc, PARALLEL_KEY_PENDING_SYNCS,
+									   false);
+	RestorePendingSyncs(pendingsyncsspace);
 	relmapperspace = shm_toc_lookup(toc, PARALLEL_KEY_RELMAPPER_STATE, false);
 	RestoreRelationMap(relmapperspace);
 	reindexspace = shm_toc_lookup(toc, PARALLEL_KEY_REINDEX_STATE, false);
 	RestoreReindexState(reindexspace);
-
-	/* Restore combo CID state. */
 	combocidspace = shm_toc_lookup(toc, PARALLEL_KEY_COMBO_CID, false);
 	RestoreComboCIDState(combocidspace);
 
@@ -1488,11 +1489,6 @@ ParallelWorkerMain(Datum main_arg)
 	SetTempNamespaceState(fps->temp_namespace_id,
 						  fps->temp_toast_namespace_id);
 
-	/* Restore pending syncs. */
-	pendingsyncsspace = shm_toc_lookup(toc, PARALLEL_KEY_PENDING_SYNCS,
-									   false);
-	RestorePendingSyncs(pendingsyncsspace);
-
 	/* Restore uncommitted enums. */
 	uncommittedenumsspace = shm_toc_lookup(toc, PARALLEL_KEY_UNCOMMITTEDENUMS,
 										   false);