From 772faafca1b288c4dd66b7150a7831c27b768003 Mon Sep 17 00:00:00 2001
From: Alexander Korotkov <akorotkov@postgresql.org>
Date: Thu, 11 Apr 2024 16:30:32 +0300
Subject: Revert: Implement pg_wal_replay_wait() stored procedure

This commit reverts 06c418e163, e37662f221, bf1e650806, 25f42429e2,
ee79928441, and 74eaf66f98 per review by Heikki Linnakangas.

Discussion: https://postgr.es/m/b155606b-e744-4218-bda5-29379779da1a%40iki.fi
---
 doc/src/sgml/func.sgml | 113 -------------------------------------------------
 1 file changed, 113 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index f017c2ef047..b432914dc88 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -28770,119 +28770,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.
    </para>
 
-   <para>
-    There are also procedures to control the progress of recovery.
-    They are shown in <xref linkend="procedures-recovery-control-table"/>.
-    These procedures may be executed only during recovery.
-   </para>
-
-   <table id="procedures-recovery-control-table">
-    <title>Recovery Control Procedures</title>
-    <tgroup cols="1">
-     <thead>
-      <row>
-       <entry role="func_table_entry"><para role="func_signature">
-        Procedure
-       </para>
-       <para>
-        Description
-       </para></entry>
-      </row>
-     </thead>
-
-     <tbody>
-      <row>
-       <entry role="func_table_entry"><para role="func_signature">
-        <indexterm>
-         <primary>pg_wal_replay_wait</primary>
-        </indexterm>
-        <function>pg_wal_replay_wait</function> (
-          <parameter>target_lsn</parameter> <type>pg_lsn</type>,
-          <parameter>timeout</parameter> <type>bigint</type> <literal>DEFAULT</literal> <literal>0</literal>)
-        <returnvalue>void</returnvalue>
-       </para>
-       <para>
-        If <parameter>timeout</parameter> is not specified or zero, this
-        procedure returns once WAL is replayed upto
-        <literal>target_lsn</literal>.
-        If the <parameter>timeout</parameter> is specified (in
-        milliseconds) and greater than zero, the procedure waits until the
-        server actually replays the WAL upto <literal>target_lsn</literal> or
-        until the given time has passed. On timeout, an error is emitted.
-       </para></entry>
-      </row>
-     </tbody>
-    </tgroup>
-   </table>
-
-   <para>
-    <function>pg_wal_replay_wait</function> waits till
-    <parameter>target_lsn</parameter> to be replayed on standby.
-    That is, after this function execution, the value returned by
-    <function>pg_last_wal_replay_lsn</function> should be greater or equal
-    to the <parameter>target_lsn</parameter> value.  This is useful to achieve
-    read-your-writes-consistency, while using async replica for reads and
-    primary for writes.  In that case <acronym>lsn</acronym> of the last
-    modification should be stored on the client application side or the
-    connection pooler side.
-   </para>
-
-   <para>
-    You can use <function>pg_wal_replay_wait</function> to wait for
-    the <type>pg_lsn</type> value.  For example, an application could update
-    the <literal>movie</literal> table and get the <acronym>lsn</acronym> after
-    changes just made.  This example uses <function>pg_current_wal_insert_lsn</function>
-    on primary server to get the <acronym>lsn</acronym> given that
-    <varname>synchronous_commit</varname> could be set to
-    <literal>off</literal>.
-
-   <programlisting>
-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)
-   </programlisting>
-
-   Then an application could run <function>pg_wal_replay_wait</function>
-   with the <acronym>lsn</acronym> obtained from primary.  After that the
-   changes made of primary should be guaranteed to be visible on replica.
-
-   <programlisting>
-postgres=# CALL pg_wal_replay_wait('0/306EE20');
-CALL
-postgres=# SELECT * FROM movie WHERE genre = 'Drama';
- genre
--------
-(0 rows)
-   </programlisting>
-
-   It may also happen that target <acronym>lsn</acronym> is not achieved
-   within the timeout.  In that case the error is thrown.
-
-   <programlisting>
-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
-    </programlisting>
-
-   </para>
-
-   <para>
-     <function>pg_wal_replay_wait</function> can't be used within
-     the transaction, another procedure or function.  Any of them holds a
-     snapshot, which could prevent the replay of WAL records.
-
-   <programlisting>
-postgres=# BEGIN;
-BEGIN
-postgres=*# CALL pg_wal_replay_wait('0/306EE20');
-ERROR:  pg_wal_replay_wait() must be only called in non-atomic context
-DETAIL:  Make sure pg_wal_replay_wait() isn't called within a transaction, another procedure, or a function.
-   </programlisting>
-
-   </para>
   </sect2>
 
   <sect2 id="functions-snapshot-synchronization">
-- 
cgit v1.2.3