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

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Kartyshov Ivan <i(dot)kartyshov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [HACKERS] make async slave to wait for lsn to be replayed
Date: 2020-04-07 12:16:09
Message-ID: CAPpHfdsEj+nFQY7r1VcqVGYUDdn8oJeuSbj-jfifK2m1HX3ONQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Apr 7, 2020 at 3:07 PM Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message John Naylor 2020-04-07 12:16:47 Re: Use compiler intrinsics for bit ops in hash
Previous Message Andres Freund 2020-04-07 12:15:03 Re: Improving connection scalability: GetSnapshotData()