@@ -28770,119 +28770,6 @@ postgres=# SELECT '0/0'::pg_lsn + pd.segment_number * ps.setting::int + :offset
28770
28770
the pause, the rate of WAL generation and available disk space.
28771
28771
</para>
28772
28772
28773
- <para>
28774
- There are also procedures to control the progress of recovery.
28775
- They are shown in <xref linkend="procedures-recovery-control-table"/>.
28776
- These procedures may be executed only during recovery.
28777
- </para>
28778
-
28779
- <table id="procedures-recovery-control-table">
28780
- <title>Recovery Control Procedures</title>
28781
- <tgroup cols="1">
28782
- <thead>
28783
- <row>
28784
- <entry role="func_table_entry"><para role="func_signature">
28785
- Procedure
28786
- </para>
28787
- <para>
28788
- Description
28789
- </para></entry>
28790
- </row>
28791
- </thead>
28792
-
28793
- <tbody>
28794
- <row>
28795
- <entry role="func_table_entry"><para role="func_signature">
28796
- <indexterm>
28797
- <primary>pg_wal_replay_wait</primary>
28798
- </indexterm>
28799
- <function>pg_wal_replay_wait</function> (
28800
- <parameter>target_lsn</parameter> <type>pg_lsn</type>,
28801
- <parameter>timeout</parameter> <type>bigint</type> <literal>DEFAULT</literal> <literal>0</literal>)
28802
- <returnvalue>void</returnvalue>
28803
- </para>
28804
- <para>
28805
- If <parameter>timeout</parameter> is not specified or zero, this
28806
- procedure returns once WAL is replayed upto
28807
- <literal>target_lsn</literal>.
28808
- If the <parameter>timeout</parameter> is specified (in
28809
- milliseconds) and greater than zero, the procedure waits until the
28810
- server actually replays the WAL upto <literal>target_lsn</literal> or
28811
- until the given time has passed. On timeout, an error is emitted.
28812
- </para></entry>
28813
- </row>
28814
- </tbody>
28815
- </tgroup>
28816
- </table>
28817
-
28818
- <para>
28819
- <function>pg_wal_replay_wait</function> waits till
28820
- <parameter>target_lsn</parameter> to be replayed on standby.
28821
- That is, after this function execution, the value returned by
28822
- <function>pg_last_wal_replay_lsn</function> should be greater or equal
28823
- to the <parameter>target_lsn</parameter> value. This is useful to achieve
28824
- read-your-writes-consistency, while using async replica for reads and
28825
- primary for writes. In that case <acronym>lsn</acronym> of the last
28826
- modification should be stored on the client application side or the
28827
- connection pooler side.
28828
- </para>
28829
-
28830
- <para>
28831
- You can use <function>pg_wal_replay_wait</function> to wait for
28832
- the <type>pg_lsn</type> value. For example, an application could update
28833
- the <literal>movie</literal> table and get the <acronym>lsn</acronym> after
28834
- changes just made. This example uses <function>pg_current_wal_insert_lsn</function>
28835
- on primary server to get the <acronym>lsn</acronym> given that
28836
- <varname>synchronous_commit</varname> could be set to
28837
- <literal>off</literal>.
28838
-
28839
- <programlisting>
28840
- postgres=# UPDATE movie SET genre = 'Dramatic' WHERE genre = 'Drama';
28841
- UPDATE 100
28842
- postgres=# SELECT pg_current_wal_insert_lsn();
28843
- pg_current_wal_insert_lsn
28844
- --------------------
28845
- 0/306EE20
28846
- (1 row)
28847
- </programlisting>
28848
-
28849
- Then an application could run <function>pg_wal_replay_wait</function>
28850
- with the <acronym>lsn</acronym> obtained from primary. After that the
28851
- changes made of primary should be guaranteed to be visible on replica.
28852
-
28853
- <programlisting>
28854
- postgres=# CALL pg_wal_replay_wait('0/306EE20');
28855
- CALL
28856
- postgres=# SELECT * FROM movie WHERE genre = 'Drama';
28857
- genre
28858
- -------
28859
- (0 rows)
28860
- </programlisting>
28861
-
28862
- It may also happen that target <acronym>lsn</acronym> is not achieved
28863
- within the timeout. In that case the error is thrown.
28864
-
28865
- <programlisting>
28866
- postgres=# CALL pg_wal_replay_wait('0/306EE20', 100);
28867
- ERROR: timed out while waiting for target LSN 0/306EE20 to be replayed; current replay LSN 0/306EA60
28868
- </programlisting>
28869
-
28870
- </para>
28871
-
28872
- <para>
28873
- <function>pg_wal_replay_wait</function> can't be used within
28874
- the transaction, another procedure or function. Any of them holds a
28875
- snapshot, which could prevent the replay of WAL records.
28876
-
28877
- <programlisting>
28878
- postgres=# BEGIN;
28879
- BEGIN
28880
- postgres=*# CALL pg_wal_replay_wait('0/306EE20');
28881
- ERROR: pg_wal_replay_wait() must be only called in non-atomic context
28882
- DETAIL: Make sure pg_wal_replay_wait() isn't called within a transaction, another procedure, or a function.
28883
- </programlisting>
28884
-
28885
- </para>
28886
28773
</sect2>
28887
28774
28888
28775
<sect2 id="functions-snapshot-synchronization">
0 commit comments