agora inbox for [email protected]help / color / mirror / Atom feed
[PATCH v50 1/8] Make index_concurrently_create_copy more general 315+ messages / 2 participants [nested] [flat]
* [PATCH v50 1/8] Make index_concurrently_create_copy more general @ 2026-03-24 18:02 Álvaro Herrera <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Álvaro Herrera @ 2026-03-24 18:02 UTC (permalink / raw) Add a 'boolean concurrent' option, and make it work for both cases. Also rename it to index_create_copy. This allows it to be reused for other purposes -- specifically, for REPACK CONCURRENTLY. With the CONCURRENTLY option, REPACK cannot simply swap the heap file and rebuild its indexes. Instead, it needs to build a separate set of indexes (including system catalog entries) *before* the actual swap, to reduce the time AccessExclusiveLock needs to be held for. This approach is different from what CREATE INDEX CONCURRENTLY does. Per a suggestion from Mihail Nikalayeu. Author: Antonin Houska <[email protected]> Discussion: https://postgr.es/m/41104.1754922120@localhost --- src/backend/catalog/index.c | 41 ++++++++++++++++++++++---------- src/backend/commands/indexcmds.c | 9 +++---- src/include/catalog/index.h | 7 +++--- 3 files changed, 36 insertions(+), 21 deletions(-) diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c index 1ccfa687f05..e418d67e8e4 100644 --- a/src/backend/catalog/index.c +++ b/src/backend/catalog/index.c @@ -1289,17 +1289,17 @@ index_create(Relation heapRelation, } /* - * index_concurrently_create_copy + * index_create_copy * - * Create concurrently an index based on the definition of the one provided by - * caller. The index is inserted into catalogs and needs to be built later - * on. This is called during concurrent reindex processing. + * Create an index based on the definition of the one provided by caller. The + * index is inserted into catalogs. If 'concurrently' is TRUE, it needs to be + * built later on; otherwise it's built immediately. * * "tablespaceOid" is the tablespace to use for this index. */ Oid -index_concurrently_create_copy(Relation heapRelation, Oid oldIndexId, - Oid tablespaceOid, const char *newName) +index_create_copy(Relation heapRelation, bool concurrently, + Oid oldIndexId, Oid tablespaceOid, const char *newName) { Relation indexRelation; IndexInfo *oldInfo, @@ -1318,6 +1318,7 @@ index_concurrently_create_copy(Relation heapRelation, Oid oldIndexId, List *indexColNames = NIL; List *indexExprs = NIL; List *indexPreds = NIL; + int flags = 0; indexRelation = index_open(oldIndexId, RowExclusiveLock); @@ -1328,7 +1329,7 @@ index_concurrently_create_copy(Relation heapRelation, Oid oldIndexId, * Concurrent build of an index with exclusion constraints is not * supported. */ - if (oldInfo->ii_ExclusionOps != NULL) + if (oldInfo->ii_ExclusionOps != NULL && concurrently) ereport(ERROR, (errcode(ERRCODE_FEATURE_NOT_SUPPORTED), errmsg("concurrent index creation for exclusion constraints is not supported"))); @@ -1384,9 +1385,7 @@ index_concurrently_create_copy(Relation heapRelation, Oid oldIndexId, } /* - * Build the index information for the new index. Note that rebuild of - * indexes with exclusion constraints is not supported, hence there is no - * need to fill all the ii_Exclusion* fields. + * Build the index information for the new index. */ newInfo = makeIndexInfo(oldInfo->ii_NumIndexAttrs, oldInfo->ii_NumIndexKeyAttrs, @@ -1395,11 +1394,24 @@ index_concurrently_create_copy(Relation heapRelation, Oid oldIndexId, indexPreds, oldInfo->ii_Unique, oldInfo->ii_NullsNotDistinct, - false, /* not ready for inserts */ - true, + !concurrently, /* isready */ + concurrently, /* concurrent */ indexRelation->rd_indam->amsummarizing, oldInfo->ii_WithoutOverlaps); + /* fetch exclusion constraint info if any */ + if (indexRelation->rd_index->indisexclusion) + { + /* + * XXX Beware: we're making newInfo point to oldInfo-owned memory. It + * would be more orthodox to palloc+memcpy, but we don't need that + * here at present. + */ + newInfo->ii_ExclusionOps = oldInfo->ii_ExclusionOps; + newInfo->ii_ExclusionProcs = oldInfo->ii_ExclusionProcs; + newInfo->ii_ExclusionStrats = oldInfo->ii_ExclusionStrats; + } + /* * Extract the list of column names and the column numbers for the new * index information. All this information will be used for the index @@ -1436,6 +1448,9 @@ index_concurrently_create_copy(Relation heapRelation, Oid oldIndexId, stattargets[i].isnull = isnull; } + if (concurrently) + flags = INDEX_CREATE_SKIP_BUILD | INDEX_CREATE_CONCURRENT; + /* * Now create the new index. * @@ -1459,7 +1474,7 @@ index_concurrently_create_copy(Relation heapRelation, Oid oldIndexId, indcoloptions->values, stattargets, reloptionsDatum, - INDEX_CREATE_SKIP_BUILD | INDEX_CREATE_CONCURRENT, + flags, 0, true, /* allow table to be a system catalog? */ false, /* is_internal? */ diff --git a/src/backend/commands/indexcmds.c b/src/backend/commands/indexcmds.c index 373e8234794..cba379810c7 100644 --- a/src/backend/commands/indexcmds.c +++ b/src/backend/commands/indexcmds.c @@ -3989,10 +3989,11 @@ ReindexRelationConcurrently(const ReindexStmt *stmt, Oid relationOid, const Rein tablespaceid = indexRel->rd_rel->reltablespace; /* Create new index definition based on given index */ - newIndexId = index_concurrently_create_copy(heapRel, - idx->indexId, - tablespaceid, - concurrentName); + newIndexId = index_create_copy(heapRel, + true, + idx->indexId, + tablespaceid, + concurrentName); /* * Now open the relation of the new index, a session-level lock is diff --git a/src/include/catalog/index.h b/src/include/catalog/index.h index a38e95bc0eb..ed9e4c37d27 100644 --- a/src/include/catalog/index.h +++ b/src/include/catalog/index.h @@ -101,10 +101,9 @@ extern Oid index_create(Relation heapRelation, #define INDEX_CONSTR_CREATE_REMOVE_OLD_DEPS (1 << 4) #define INDEX_CONSTR_CREATE_WITHOUT_OVERLAPS (1 << 5) -extern Oid index_concurrently_create_copy(Relation heapRelation, - Oid oldIndexId, - Oid tablespaceOid, - const char *newName); +extern Oid index_create_copy(Relation heapRelation, bool concurrently, + Oid oldIndexId, Oid tablespaceOid, + const char *newName); extern void index_concurrently_build(Oid heapRelationId, Oid indexRelationId); -- 2.47.3 --brnevsqjnuzpyok4 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v50-0002-Rename-cluster.c-h-repack.c-h.patch" ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' @ 2026-04-07 13:11 Andres Freund <[email protected]> 0 siblings, 0 replies; 315+ messages in thread From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw) The investigation into the negative test performance impact of 7e8aeb9e483 lead to discovering that there are a few issues with WAIT FOR. This commit is just a minimal fix to prevent hangs in standby_flush mode, due to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver does not receive any writes, because the stanby is already caught up. There are several other issues and this is isn't necessarily the best fix. But this way we get the hangs out of the way. Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz --- src/backend/replication/walreceiver.c | 2 -- src/backend/replication/walreceiverfuncs.c | 1 + 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c index a437273cf9a..09fde92bfd7 100644 --- a/src/backend/replication/walreceiver.c +++ b/src/backend/replication/walreceiver.c @@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len) SpinLockRelease(&walrcv->mutex); - pg_atomic_write_u64(&WalRcv->writtenUpto, 0); - /* Arrange to clean up at walreceiver exit */ on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI)); diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c index 4e03e721872..bd5d47be964 100644 --- a/src/backend/replication/walreceiverfuncs.c +++ b/src/backend/replication/walreceiverfuncs.c @@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo, walrcv->flushedUpto = recptr; walrcv->receivedTLI = tli; walrcv->latestChunkStart = recptr; + pg_atomic_write_u64(&walrcv->writtenUpto, recptr); } walrcv->receiveStart = recptr; walrcv->receiveStartTLI = tli; -- 2.53.0.1.gb2826b52eb --ags3ltqh73mz7p2n-- ^ permalink raw reply [nested|flat] 315+ messages in thread
end of thread, other threads:[~2026-04-07 13:11 UTC | newest] Thread overview: 315+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-03-24 18:02 [PATCH v50 1/8] Make index_concurrently_create_copy more general Álvaro Herrera <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]> 2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox