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
