From 3a7ae6b3d91e0d011dba1eb8a29e1836c6a33c75 Mon Sep 17 00:00:00 2001
From: Alexander Korotkov
Date: Mon, 4 Nov 2024 22:43:08 +0200
Subject: Revert pg_wal_replay_wait() stored procedure
This commit reverts 3c5db1d6b0, and subsequent improvements and fixes
including 8036d73ae3, 867d396ccd, 3ac3ec580c, 0868d7ae70, 85b98b8d5a,
2520226c95, 014f9f34d2, e658038772, e1555645d7, 5035172e4a, 6cfebfe88b,
73da6b8d1b, and e546989a26.
The reason for reverting is a set of remaining issues. Most notably, the
stored procedure appears to need more effort than the utility statement
to turn the backend into a "snapshot-less" state. This makes an approach
to use stored procedures questionable.
Catversion is bumped.
Discussion: https://postgr.es/m/Zyhj2anOPRKtb0xW%40paquier.xyz
---
doc/src/sgml/func.sgml | 170 -------------------------------------------------
1 file changed, 170 deletions(-)
(limited to 'doc/src')
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index cd525eac056..73979f20fff 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -29000,176 +29000,6 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset
the pause, the rate of WAL generation and available disk space.
-
- The procedure shown in
- can be executed only during recovery.
-
-
-
- Recovery Synchronization Procedure and Function
-
-
-
-
- Procedure or Function
-
-
- Type
-
-
- Description
-
-
-
-
-
-
-
-
- pg_wal_replay_wait
-
- pg_wal_replay_wait (
- target_lsn pg_lsn,
- timeout bigint DEFAULT 0,
- no_error bool DEFAULT false)
-
-
- Procedure
-
-
- Waits until recovery replays target_lsn.
- If no timeout is specified or it is set to
- zero, this procedure waits indefinitely for the
- target_lsn. If the timeout
- is specified (in milliseconds) and is greater than zero, the
- procedure waits until target_lsn is reached or
- the specified timeout has elapsed.
- On timeout, or if the server is promoted before
- target_lsn is reached, an error is emitted,
- as soon as no_error is false.
- If no_error is set to true, then the procedure
- doesn't throw errors. The last result status could be read
- with pg_wal_replay_wait_status.
-
-
-
-
-
-
- pg_wal_replay_wait_status
-
- pg_wal_replay_wait_status ()
- text
-
-
- Function
-
-
- Returns the last result status for
- pg_wal_replay_wait procedure. The possible
- values are success, timeout,
- and not in recovery.
-
-
-
-
-
-
-
- pg_wal_replay_wait waits till
- target_lsn to be replayed on standby.
- That is, after this function execution, the value returned by
- pg_last_wal_replay_lsn should be greater or equal
- to the target_lsn value. This is useful to achieve
- read-your-writes-consistency, while using async replica for reads and
- primary for writes. In that case lsn of the last
- modification should be stored on the client application side or the
- connection pooler side.
-
-
-
- pg_wal_replay_wait should be called on standby.
- If a user calls pg_wal_replay_wait on primary, it
- will error out as soon as no_error is false.
- However, if pg_wal_replay_wait is
- called on primary promoted from standby and target_lsn
- was already replayed, then pg_wal_replay_wait just
- exits immediately.
-
-
-
- You can use pg_wal_replay_wait to wait for
- the pg_lsn value. For example, an application could update
- the movie table and get the lsn after
- changes just made. This example uses pg_current_wal_insert_lsn
- on primary server to get the lsn given that
- synchronous_commit could be set to
- off.
-
-
-postgres=# UPDATE movie SET genre = 'Dramatic' WHERE genre = 'Drama';
-UPDATE 100
-postgres=# SELECT pg_current_wal_insert_lsn();
-pg_current_wal_insert_lsn
---------------------
-0/306EE20
-(1 row)
-
-
- Then an application could run pg_wal_replay_wait
- with the lsn obtained from primary. After that the
- changes made on primary should be guaranteed to be visible on replica.
-
-
-postgres=# CALL pg_wal_replay_wait('0/306EE20');
-CALL
-postgres=# SELECT * FROM movie WHERE genre = 'Drama';
- genre
--------
-(0 rows)
-
-
- It may also happen that target lsn is not reached
- within the timeout. In that case the error is thrown.
-
-
-postgres=# CALL pg_wal_replay_wait('0/306EE20', 100);
-ERROR: timed out while waiting for target LSN 0/306EE20 to be replayed; current replay LSN 0/306EA60
-
-
- The same example uses pg_wal_replay_wait with
- no_error set to true. In this case, the result
- status must be read with pg_wal_replay_wait_status.
-
-
-postgres=# CALL pg_wal_replay_wait('0/306EE20', 100, true);
-CALL
-postgres=# SELECT pg_wal_replay_wait_status();
- pg_wal_replay_wait_status
----------------------------
- timeout
-(1 row)
-
-
-
-
-
- pg_wal_replay_wait can't be used within
- a transaction with an isolation level higher than
- READ COMMITTED, another procedure, or a function.
- All the cases above imply holding a snapshot, which could prevent
- WAL records from replaying (see )
- and cause an indirect deadlock.
-
-
-postgres=# BEGIN;
-BEGIN
-postgres=*# CALL pg_wal_replay_wait('0/306EE20');
-ERROR: pg_wal_replay_wait() must be only called without an active or registered snapshot
-DETAIL: Make sure pg_wal_replay_wait() isn't called within a transaction with an isolation level higher than READ COMMITTED, another procedure, or a function.
-
-
-
--
cgit v1.2.3