From 3e0d80fd8d3dd4f999e0d3aa3e591f480d8ad1fd Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Fri, 3 Apr 2020 22:28:37 -0400 Subject: [PATCH] Fix resource management bug with replication=database. Commit 0d8c9c1210c44b36ec2efcb223a1dfbe897a3661 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. --- src/backend/replication/walsender.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index 3b117d8367..9e5611574c 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -315,7 +315,13 @@ WalSndErrorCleanup(void) replication_active = false; - WalSndResourceCleanup(false); + /* + * If there is a transaction in progress, it will clean up our + * ResourceOwner, but if a replication command set up a resource owner + * without a transaction, we've got to clean that up now. + */ + if (!IsTransactionOrTransactionBlock()) + WalSndResourceCleanup(false); if (got_STOPPING || got_SIGUSR2) proc_exit(0); -- 2.39.5