Re: [HACKERS] make async slave to wait for lsn to be replayed - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id 20200410193301.2qsbuoieppkst7xj@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Hi,

On 2020-04-10 11:25:02 +0900, Fujii Masao wrote:
> > BEGIN
> > WAIT (LSN '16/B374D848', WHATEVER_OPTION_YOU_WANT);
> > ...
> > COMMIT;
> > 
> > It requires only one reserved keyword 'WAIT'. The advantage of this approach is that it can be extended to support
xid,timestamp, csn or anything else, that may be invented in the future, without affecting the grammar.
 
> > 
> > What do you think?
> > 
> > Personally, I find this syntax to be more convenient and human-readable compared with function call:
> > 
> > SELECT pg_wait_for_lsn('16/B374D848');
> > BEGIN;
> 
> I can imagine that some users want to specify the LSN to wait for,
> from the result of another query, for example,
> SELECT pg_wait_for_lsn(lsn) FROM xxx. If this is valid use case,
> isn't the function better?

I don't think a function is a good idea - it'll cause a snapshot to be
held while waiting. Which in turn will cause hot_standby_feedback to not
be able to report an increased xmin up. And it will possibly hit
snapshot recovery conflicts.

Whereas explicit syntax, especially if a transaction control statement,
won't have that problem.

I'd personally look at 'AFTER' instead of 'WAIT'. Upthread you talked
about a reserved keyword - why does it have to be reserved?


FWIW, I'm not really convinced there needs to be bespoke timeout syntax
for this feature. I can see reasons why you'd not just want to rely on
statement_timeout, but at least that should be discussed.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: pg_validatebackup -> pg_verifybackup?
Next
From: Julien Rouhaud
Date:
Subject: Re: WAL usage calculation patch