database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Use replay position as floor for WAIT FOR LSN standby_(write|flush)

Browse Source 
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 29e7dbf5e4, 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 <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/1957514.1775526774%40sss.pgh.pa.us
Author: Xuneng Zhou <xunengzhou@gmail.com>
Reviewed-by: Andres Freund <andres@anarazel.de>
Reviewed-by: Alexander Korotkov <aekorotkov@gmail.com>
This commit is contained in:
Alexander Korotkov
2026-05-03 16:18:30 +03:00
parent df9f938ca2
commit cba67b5b87
3 changed files with 109 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
doc/src/sgml/ref/wait_for.sgml
View File

@@ -105,30 +105,25 @@ WAIT FOR LSN '<replaceable class="parameter">lsn</replaceable>'
<listitem>
<para>
<literal>standby_write</literal>: Wait for the WAL containing the
LSN to be received from the primary and written to disk on a
standby server, but not yet flushed. This is faster than
LSN to be written to disk on a standby server, but not yet
necessarily flushed. This is faster than
<literal>standby_flush</literal> but provides weaker durability
guarantees since the data may still be in operating system
buffers. After successful completion, the
<structfield>written_lsn</structfield> column in
<link linkend="monitoring-pg-stat-wal-receiver-view">
<structname>pg_stat_wal_receiver</structname></link> will show
a value greater than or equal to the target LSN. This mode can
only be used during recovery.
buffers. This is satisfied by WAL already present on the
standby from a base backup, archive restore, or prior
streaming, as well as WAL newly received from the primary.
This mode can only be used during recovery.
</para>
</listitem>
<listitem>
<para>
<literal>standby_flush</literal>: Wait for the WAL containing the
LSN to be received from the primary and flushed to disk on a
standby server. This provides a durability guarantee without
waiting for the WAL to be applied. After successful completion,
<function>pg_last_wal_receive_lsn()</function> will return a
value greater than or equal to the target LSN. This value is
also available as the <structfield>flushed_lsn</structfield>
column in <link linkend="monitoring-pg-stat-wal-receiver-view">
<structname>pg_stat_wal_receiver</structname></link>. This mode
can only be used during recovery.
LSN to be flushed to disk on a standby server. This provides
a durability guarantee without waiting for the WAL to be
applied. This is satisfied by WAL already present on the
standby from a base backup, archive restore, or prior
streaming, as well as WAL newly received from the primary.
This mode can only be used during recovery.
</para>
</listitem>
<listitem>
@@ -238,10 +233,11 @@ WAIT FOR LSN '<replaceable class="parameter">lsn</replaceable>'
useful to achieve read-your-writes consistency while using an async
replica for reads and the primary for writes. The
<literal>standby_flush</literal> mode waits for the WAL to be flushed
to durable storage on the replica, providing a durability guarantee
without waiting for replay. The <literal>standby_write</literal> mode
waits for the WAL to be written to the operating system, which is
faster than flush but provides weaker durability guarantees. The
to durable storage on the replica, or to have already been replayed
from WAL present on the standby. The <literal>standby_write</literal> mode
waits for the WAL to be written to the operating system, or to have
already been replayed, which is faster than flush for newly received
WAL but provides weaker durability guarantees. The
<literal>primary_flush</literal> mode waits for WAL to be flushed on
a primary server. In all cases, the <acronym>LSN</acronym> of the last
modification should be stored on the client application side or the