agora inbox for [email protected]  

help / color / mirror / Atom feed

[PATCH 3/6] Move conversion of a "historic" to MVCC snapshot to a separate function.
130+ messages / 2 participants
[nested] [flat]

* [PATCH 3/6] Move conversion of a "historic" to MVCC snapshot to a separate function.
@ 2026-01-27 10:48  Antonin Houska <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Antonin Houska @ 2026-01-27 10:48 UTC (permalink / raw)

The conversion is now handled by SnapBuildMVCCFromHistoric(). REPACK
CONCURRENTLY will also need it.
---
 src/backend/replication/logical/snapbuild.c | 59 +++++++++++++++++----
 src/backend/utils/time/snapmgr.c            |  3 +-
 src/include/replication/snapbuild.h         |  1 +
 src/include/utils/snapmgr.h                 |  1 +
 4 files changed, 52 insertions(+), 12 deletions(-)

diff --git a/src/backend/replication/logical/snapbuild.c b/src/backend/replication/logical/snapbuild.c
index 7f79621b57e..a738ad8a864 100644
--- a/src/backend/replication/logical/snapbuild.c
+++ b/src/backend/replication/logical/snapbuild.c
@@ -440,10 +440,7 @@ Snapshot
 SnapBuildInitialSnapshot(SnapBuild *builder)
 {
 	Snapshot	snap;
-	TransactionId xid;
 	TransactionId safeXid;
-	TransactionId *newxip;
-	int			newxcnt = 0;
 
 	Assert(XactIsoLevel == XACT_REPEATABLE_READ);
 	Assert(builder->building_full_snapshot);
@@ -485,7 +482,35 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 
 	MyProc->xmin = snap->xmin;
 
-	/* allocate in transaction context */
+	/* Convert the historic snapshot to MVCC snapshot. */
+	return SnapBuildMVCCFromHistoric(snap, true);
+}
+
+/*
+ * Turn a historic MVCC snapshot into an ordinary MVCC snapshot.
+ *
+ * Unlike a regular (non-historic) MVCC snapshot, the 'xip' array of this
+ * snapshot contains not only running main transactions, but also their
+ * subtransactions. On the other hand, 'subxip' will usually be empty. This
+ * difference does not affect the result of XidInMVCCSnapshot() because it
+ * searches both in 'xip' and 'subxip'.
+ *
+ * Pass true for 'in_place' if you don't care about modifying the source
+ * snapshot. If you need a new instance, and one that was allocated as a
+ * single chunk of memory, pass false.
+ */
+Snapshot
+SnapBuildMVCCFromHistoric(Snapshot snapshot, bool in_place)
+{
+	TransactionId xid;
+	TransactionId *oldxip = snapshot->xip;
+	uint32		oldxcnt = snapshot->xcnt;
+	TransactionId *newxip;
+	int			newxcnt = 0;
+	Snapshot	result;
+
+	Assert(snapshot->snapshot_type == SNAPSHOT_HISTORIC_MVCC);
+
 	newxip = palloc_array(TransactionId, GetMaxSnapshotXidCount());
 
 	/*
@@ -494,7 +519,7 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 	 * classical snapshot by marking all non-committed transactions as
 	 * in-progress. This can be expensive.
 	 */
-	for (xid = snap->xmin; NormalTransactionIdPrecedes(xid, snap->xmax);)
+	for (xid = snapshot->xmin; NormalTransactionIdPrecedes(xid, snapshot->xmax);)
 	{
 		void	   *test;
 
@@ -502,7 +527,7 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 		 * Check whether transaction committed using the decoding snapshot
 		 * meaning of ->xip.
 		 */
-		test = bsearch(&xid, snap->xip, snap->xcnt,
+		test = bsearch(&xid, snapshot->xip, snapshot->xcnt,
 					   sizeof(TransactionId), xidComparator);
 
 		if (test == NULL)
@@ -519,11 +544,25 @@ SnapBuildInitialSnapshot(SnapBuild *builder)
 	}
 
 	/* adjust remaining snapshot fields as needed */
-	snap->snapshot_type = SNAPSHOT_MVCC;
-	snap->xcnt = newxcnt;
-	snap->xip = newxip;
+	snapshot->xcnt = newxcnt;
+	snapshot->xip = newxip;
+
+	if (in_place)
+		result = snapshot;
+	else
+	{
+		result = CopySnapshot(snapshot);
+
+		/* Restore the original values so the source is intact. */
+		snapshot->xip = oldxip;
+		snapshot->xcnt = oldxcnt;
+
+		/* newxip has been copied */
+		pfree(newxip);
+	}
+	result->snapshot_type = SNAPSHOT_MVCC;
 
-	return snap;
+	return result;
 }
 
 /*
diff --git a/src/backend/utils/time/snapmgr.c b/src/backend/utils/time/snapmgr.c
index 2e6197f5f35..3af1b366adf 100644
--- a/src/backend/utils/time/snapmgr.c
+++ b/src/backend/utils/time/snapmgr.c
@@ -213,7 +213,6 @@ typedef struct ExportedSnapshot
 static List *exportedSnapshots = NIL;
 
 /* Prototypes for local functions */
-static Snapshot CopySnapshot(Snapshot snapshot);
 static void UnregisterSnapshotNoOwner(Snapshot snapshot);
 static void FreeSnapshot(Snapshot snapshot);
 static void SnapshotResetXmin(void);
@@ -604,7 +603,7 @@ SetTransactionSnapshot(Snapshot sourcesnap, VirtualTransactionId *sourcevxid,
  * The copy is palloc'd in TopTransactionContext and has initial refcounts set
  * to 0.  The returned snapshot has the copied flag set.
  */
-static Snapshot
+Snapshot
 CopySnapshot(Snapshot snapshot)
 {
 	Snapshot	newsnap;
diff --git a/src/include/replication/snapbuild.h b/src/include/replication/snapbuild.h
index ccded021433..34383dea776 100644
--- a/src/include/replication/snapbuild.h
+++ b/src/include/replication/snapbuild.h
@@ -73,6 +73,7 @@ extern void FreeSnapshotBuilder(SnapBuild *builder);
 extern void SnapBuildSnapDecRefcount(Snapshot snap);
 
 extern Snapshot SnapBuildInitialSnapshot(SnapBuild *builder);
+extern Snapshot SnapBuildMVCCFromHistoric(Snapshot snapshot, bool in_place);
 extern const char *SnapBuildExportSnapshot(SnapBuild *builder);
 extern void SnapBuildClearExportedSnapshot(void);
 extern void SnapBuildResetExportedSnapshotState(void);
diff --git a/src/include/utils/snapmgr.h b/src/include/utils/snapmgr.h
index b8c01a291a1..de824945f0b 100644
--- a/src/include/utils/snapmgr.h
+++ b/src/include/utils/snapmgr.h
@@ -63,6 +63,7 @@ extern Snapshot GetTransactionSnapshot(void);
 extern Snapshot GetLatestSnapshot(void);
 extern void SnapshotSetCommandId(CommandId curcid);
 
+extern Snapshot CopySnapshot(Snapshot snapshot);
 extern Snapshot GetCatalogSnapshot(Oid relid);
 extern Snapshot GetNonHistoricCatalogSnapshot(Oid relid);
 extern void InvalidateCatalogSnapshot(void);
-- 
2.47.3


--=-=-=
Content-Type: text/plain
Content-Disposition: attachment;
 filename=v32-0004-Add-CONCURRENTLY-option-to-REPACK-command.patch



^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

* [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush'
@ 2026-04-07 13:11  Andres Freund <[email protected]>
  0 siblings, 0 replies; 130+ messages in thread

From: Andres Freund @ 2026-04-07 13:11 UTC (permalink / raw)

The investigation into the negative test performance impact of 7e8aeb9e483
lead to discovering that there are a few issues with WAIT FOR.

This commit is just a minimal fix to prevent hangs in standby_flush mode, due
to WAIT FOR ... 'standby_flush' seeing a 0 LSN if a newly started walreceiver
does not receive any writes, because the stanby is already caught up.

There are several other issues and this is isn't necessarily the best fix. But
this way we get the hangs out of the way.

Reported-by: Tom Lane <[email protected]>
Discussion: https://postgr.es/m/zqbppucpmkeqecfy4s5kscnru4tbk6khp3ozqz6ad2zijz354k@w4bdf4z3wqoz
---
 src/backend/replication/walreceiver.c      | 2 --
 src/backend/replication/walreceiverfuncs.c | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/backend/replication/walreceiver.c b/src/backend/replication/walreceiver.c
index a437273cf9a..09fde92bfd7 100644
--- a/src/backend/replication/walreceiver.c
+++ b/src/backend/replication/walreceiver.c
@@ -242,8 +242,6 @@ WalReceiverMain(const void *startup_data, size_t startup_data_len)
 
 	SpinLockRelease(&walrcv->mutex);
 
-	pg_atomic_write_u64(&WalRcv->writtenUpto, 0);
-
 	/* Arrange to clean up at walreceiver exit */
 	on_shmem_exit(WalRcvDie, PointerGetDatum(&startpointTLI));
 
diff --git a/src/backend/replication/walreceiverfuncs.c b/src/backend/replication/walreceiverfuncs.c
index 4e03e721872..bd5d47be964 100644
--- a/src/backend/replication/walreceiverfuncs.c
+++ b/src/backend/replication/walreceiverfuncs.c
@@ -321,6 +321,7 @@ RequestXLogStreaming(TimeLineID tli, XLogRecPtr recptr, const char *conninfo,
 		walrcv->flushedUpto = recptr;
 		walrcv->receivedTLI = tli;
 		walrcv->latestChunkStart = recptr;
+		pg_atomic_write_u64(&walrcv->writtenUpto, recptr);
 	}
 	walrcv->receiveStart = recptr;
 	walrcv->receiveStartTLI = tli;
-- 
2.53.0.1.gb2826b52eb


--ags3ltqh73mz7p2n--





^ permalink  raw  reply  [nested|flat] 130+ messages in thread

end of thread, other threads:[~2026-04-07 13:11 UTC | newest]

Thread overview: 130+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-01-27 10:48 [PATCH 3/6] Move conversion of a "historic" to MVCC snapshot to a separate function. Antonin Houska <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_flush' Andres Freund <[email protected]>
2026-04-07 13:11 [PATCH v1] Minimal fix for WAIT FOR ... MODE 'standby_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