pg.ddx.io  pgsql-committers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Alexander Korotkov <aekorotkov@gmail.com>
To: Pavel Borisov <pashkin.elfe@gmail.com>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-committers@lists.postgresql.org
Subject: Re: pgsql: Implement pg_wal_replay_wait() stored procedure
Date: Fri, 25 Oct 2024 09:06:10 +0300
Message-ID: <ab0eddce-06d4-4db2-87ce-46fa2427806c@iki.fi> (raw)
In-Reply-To: <CAPpHfdtc5AG0bRDaDPX+3UfwnONauGs6=vXzSKSnNs_rY8dfqg@mail.gmail.com>
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>

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)






view thread (50+ messages)  latest in thread

Message-ID: <ab0eddce-06d4-4db2-87ce-46fa2427806c@iki.fi>
Permalink:  ../ab0eddce-06d4-4db2-87ce-46fa2427806c@iki.fi/
Also on:    postgresql.org/message-id/ab0eddce-06d4-4db2-87ce-46fa2427806c@iki.fi

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-committers@postgresql.org
  Cc: hlinnaka@iki.fi, aekorotkov@gmail.com, pashkin.elfe@gmail.com, peter@eisentraut.org, michael@paquier.xyz, pgsql-committers@lists.postgresql.org
  Subject: Re: pgsql: Implement pg_wal_replay_wait() stored procedure
  In-Reply-To: <ab0eddce-06d4-4db2-87ce-46fa2427806c@iki.fi>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox