Message-ID: <ab0eddce-06d4-4db2-87ce-46fa2427806c@iki.fi>
Date: Fri, 25 Oct 2024 09:06:10 +0300
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: Implement pg_wal_replay_wait() stored procedure
To: Alexander Korotkov <aekorotkov@gmail.com>,
 Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
 Michael Paquier <michael@paquier.xyz>, pgsql-committers@lists.postgresql.org
References: <E1sZwuz-002NPQ-Lc@gemulon.postgresql.org>
 <18c0fa64-0475-415e-a1bd-665d922c5201@eisentraut.org>
 <CAPpHfduQPYWATA2rfbYXsXM+Yspn1nQVwrEs=p303O428J57Yg@mail.gmail.com>
 <ZtT4dhlxuxdPPI8t@paquier.xyz>
 <CAPpHfdubNR746cbxRvs8C0MmNvUTtrjWwZ=RzcB5i_4kUz+RuQ@mail.gmail.com>
 <1f5b399a-76b1-48e1-87b0-f511e61818f3@eisentraut.org>
 <CAPpHfdvbcTBk_yuvvg=HvWJeLOWBtdmh1_K4j4btZ70ES_HWuw@mail.gmail.com>
 <CAPpHfdut8AvtU9PhXBOd0r5LPYkLyPeiWS+sfZ0FRoUBrS3_TQ@mail.gmail.com>
 <CALT9ZEFX_9CF1y5NFMDBVM2uACWUCgsKDfCS0dNMTQ=G+iFD5g@mail.gmail.com>
 <CAPpHfdu7eAN6_Xfs+xSnRhu1zoN6WiOvj58i6qv27FgYcd8DSg@mail.gmail.com>
 <CALT9ZEERNvqJ1iDk==G_B-ZZXUBZROaEptR-zUC4mHC+iUmHUQ@mail.gmail.com>
 <CAPpHfdtc5AG0bRDaDPX+3UfwnONauGs6=vXzSKSnNs_rY8dfqg@mail.gmail.com>
Content-Language: en-US
From: Heikki Linnakangas <hlinnaka@iki.fi>
In-Reply-To: 
 <CAPpHfdtc5AG0bRDaDPX+3UfwnONauGs6=vXzSKSnNs_rY8dfqg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/ab0eddce-06d4-4db2-87ce-46fa2427806c%40iki.fi>
Precedence: bulk

If you call this procedure on a stand-alone server, you get:

postgres=# call pg_wal_replay_wait('1234/0');
ERROR:  recovery is not in progress
DETAIL:  Recovery ended before replaying target LSN 1234/0; last replay 
LSN 0/0.

The DETAIL seems a bit misleading. Recovery never ended, because it 
never started in the first place. Last replay LSN is indeed 0/0, but 
that's not helpful.

If a standby server has been promoted and you pass an LSN that's earlier 
than the last replay LSN, it returns successfully. That makes sense I 
guess; if you connect to a standby and wait for it to replay a commit 
that you made in the primary, and the standby gets promoted, that seems 
correct. But it's a little inconsistent: If the standby crashes 
immediately after promotion, and you call pg_wal_replay_wait() after 
recovery, it returns success. However, if you shut down the promoted 
server and restart it, then last replay LSN is 0/0, and the call will 
fail because no recovery happened.

What is the use case for the 'no_error' argument? Why would you ever 
want to pass no_error=true ? The separate pg_wal_replay_wait_status() 
function feels weird to me. Also it surely shouldn't be marked IMMUTABLE 
nor parallel safe.

This would benefit from more documentation, explaining how you would use 
this in practice. I believe the use case is that you want "read your 
writes" consistency between a primary and a standby. You commit a 
transaction in the primary, and you then want to run read-only queries 
in a standby, and you want to make sure that you see your own commit, 
but you're ok with slightly delayed results otherwise. It would be good 
to add a chapter somewhere in the docs to show how to do that in 
practice with these functions.

-- 
Heikki Linnakangas
Neon (https://neon.tech)