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
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() |