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

From Alexander Korotkov
Subject Re: [HACKERS] make async slave to wait for lsn to be replayed
Date
Msg-id CAPpHfdsEj+nFQY7r1VcqVGYUDdn8oJeuSbj-jfifK2m1HX3ONQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] make async slave to wait for lsn to be replayed  (Anna Akenteva <a.akenteva@postgrespro.ru>)
List pgsql-hackers
On Tue, Apr 7, 2020 at 3:07 PM Anna Akenteva <a.akenteva@postgrespro.ru> wrote:
> 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.

+1
In the latest version of patch we have very brief and simple syntax
allowing to wait for given LSN with given timeout.  In future we can
expand this syntax in different ways.  I don't see that current syntax
is limiting us from something.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Improving connection scalability: GetSnapshotData()
Next
From: John Naylor
Date:
Subject: Re: Use compiler intrinsics for bit ops in hash