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

From Tom Lane
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id 13716.1586378146@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Anna Akenteva <a.akenteva@postgrespro.ru>)
Responses Re: [HACKERS] make async slave to wait for lsn to be replayed  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Anna Akenteva <a.akenteva@postgrespro.ru> writes:
> I'd like to hear others' opinions on the syntax as well.

Pardon me for coming very late to the party, but it seems like there are
other questions that ought to be answered before we worry about any of
this.  Why is this getting grafted onto BEGIN/START TRANSACTION in the
first place?  It seems like it would be just as useful as a separate
command, if not more so.  You could always start a transaction just
after waiting.  Conversely, there might be reasons to want to wait
within an already-started transaction.

If it could survive as a separate command, then I'd humbly suggest
that it requires no grammar work at all.  You could just invent one
or more functions that take suitable parameters.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: backup manifests and contemporaneous buildfarm failures
Next
From: Justin Pryzby
Date:
Subject: Re: explain HashAggregate to report bucket and memory stats