Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 3e0d80f

Browse files
committed
Fix resource management bug with replication=database.
Commit 0d8c9c1 allowed BASE_BACKUP to acquire a ResourceOwner without a transaction so that the backup manifest functionality could use a BufFile, but it overlooked the fact that when a walsender is used with replication=database, it might have a transaction in progress, because in that mode, SQL and replication commands can be mixed. Try to fix things up so that the two cleanup mechanisms don't conflict. Per buildfarm member serinus, which triggered the problem when CREATE_REPLICATION_SLOT failed from inside a transaction. It passed on the subsequent run, so evidently the failure doesn't happen every time.
1 parent db1531c commit 3e0d80f

File tree

1 file changed

+7
-1
lines changed

1 file changed

+7
-1
lines changed

src/backend/replication/walsender.c

+7-1
Original file line numberDiff line numberDiff line change
@@ -315,7 +315,13 @@ WalSndErrorCleanup(void)
315315

316316
replication_active = false;
317317

318-
WalSndResourceCleanup(false);
318+
/*
319+
* If there is a transaction in progress, it will clean up our
320+
* ResourceOwner, but if a replication command set up a resource owner
321+
* without a transaction, we've got to clean that up now.
322+
*/
323+
if (!IsTransactionOrTransactionBlock())
324+
WalSndResourceCleanup(false);
319325

320326
if (got_STOPPING || got_SIGUSR2)
321327
proc_exit(0);

0 commit comments

Comments
 (0)