Re: [HACKERS] make async slave to wait for lsn to be replayed

On 2020-04-07 13:32, Amit Kapila wrote:
> First, I don't
> think we have a consensus on the syntax being used in the patch
> (various people didn't agree to LSN specific syntax). They wanted a
> more generic syntax and I see that we tried to implement it and it
> turns out to be a bit complex but that doesn't mean we just give up on
> the idea and take the simplest approach and that too without a broader
> agreement.

Thank you for your comments!

Initially, the syntax used to be "WAITLSN", which confined us with only
waiting for LSN-s and not anything else. So we switched to "WAIT FOR
LSN", which would allow us to add variations like "WAIT FOR XID" or
"WAIT FOR COMMIT TOKEN" in the future if we wanted. A few people seemed
to imply that this kind of syntax is expandable enough:

On 2018-02-01 14:47, Simon Riggs wrote:
> I agree that WAIT LSN is good syntax because this allows us to wait
> for something else in future.

On 2017-10-31 12:42:56, Ants Aasma wrote:
> For lack of a better proposal I would like something along the lines
> of:
> WAIT FOR state_id[, state_id] [ OPTIONS (..)]

As for giving up waiting for multiple events: we can only wait for LSN-s
at the moment, and there seems to be no point in waiting for multiple
LSN-s at once, because it's equivalent to waiting for the biggest LSN.
So we opted for simpler grammar for now, only letting the user specify
one LSN and one TIMEOUT. If in the future we allow waiting for something
else, like XID-s, we can expand the grammar as needed.

What are your own thoughts on the syntax?

--
Anna Akenteva
Postgres Professional:
The Russian Postgres Company
http://www.postgrespro.com