Use replay position as floor for WAIT FOR LSN standby_(write|flush) GetCurrentLSNForWaitType() for standby_write and standby_flush modes returned only the walreceiver position, which may lag behind WAL already present on the standby from a base backup, archive restore, or prior streaming. This could cause unnecessary blocking if the target LSN falls between the walreceiver's tracked position and the replay position.
Fix by returning the maximum of the walreceiver position and the replay position. WAL up to the replay point is physically on disk regardless of its origin, so there is no reason to wait for the walreceiver to re-receive it. This complements 29e7dbf5e4d, which seeded writtenUpto to receiveStart in RequestXLogStreaming() to fix the most common hang scenario. The getter-level floor handles the remaining edge cases: targets between receiveStart and the replay position, and standbys running with archive recovery only (no walreceiver). Reported-by: Tom Lane <[email protected]> Discussion: https://postgr.es/m/1957514.1775526774%40sss.pgh.pa.us Author: Xuneng Zhou <[email protected]> Reviewed-by: Andres Freund <[email protected]> Reviewed-by: Alexander Korotkov <[email protected]> Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/cba67b5b87f9e7a576a99d00c0cd60f7ea529ba3 Modified Files -------------- doc/src/sgml/ref/wait_for.sgml | 38 ++++++++--------- src/backend/access/transam/xlogwait.c | 21 +++++++++- src/test/recovery/t/049_wait_for_lsn.pl | 73 +++++++++++++++++++++++++++++++++ 3 files changed, 109 insertions(+), 23 deletions(-)
