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

Hi!

On Fri, Apr 3, 2020 at 9:51 PM Anna Akenteva <a(dot)akenteva(at)postgrespro(dot)ru> wrote:
> In the patch that I reviewed, you could do things like:
> WAIT FOR
> LSN lsn0,
> LSN lsn1 TIMEOUT time1,
> LSN lsn2 TIMEOUT time2;
> and such a statement was in practice equivalent to
> WAIT FOR LSN(max(lsn0, lsn1, lsn2)) TIMEOUT (max(time1, time2))
>
> As you can see, even though grammatically lsn1 is grouped with time1 and
> lsn2 is grouped with time2, both timeouts that we specified are not
> connected to their respective LSN-s, and instead they kinda act like
> global timeouts. Therefore, I didn't see a point in keeping TIMEOUT
> necessarily grammatically connected to LSN.
>
> In the new syntax our statement would look like this:
> WAIT FOR LSN lsn0, LSN lsn1, LSN lsn2, TIMEOUT time1, TIMEOUT time2;
> TIMEOUT-s are not forced to be grouped with LSN-s anymore, which makes
> it more clear that all specified TIMEOUTs will be global and will apply
> to all LSN-s at once.
>
> The point of having TIMEOUT is still to let us limit the time of waiting
> for LSNs. It's just that with the new syntax, we can also use TIMEOUT
> without an LSN. You are right, such a case is equivalent to pg_sleep.
> One way to avoid that is to prohibit waiting for TIMEOUT without
> specifying an LSN. Do you think we should do that?

I think specifying multiple LSNs/TIMEOUTs is kind of ridiculous. We
can assume that client application is smart enough to calculate
minimum/maximum on its side. When multiple LSNs/TIMEOUTs are
specified, what should we wait for? Reaching all the LSNs? Reaching
any of LSNs? Are timeouts independent from LSNs or sticked together?
So if we didn't manage to reach LSN1 in TIMEOUT1, then we don't wait
for LSN2 with TIMEOUT2 (or not)?

I think that now we would be fine with single LSN and single TIMEOUT.
In future we may add multiple LSNs/TIMEOUTs or/and support for
expressions as LSNs/TIMEOUTs if we figure out it's necessary.

I also think it's good to couple waiting for lsn with beginning of
transaction is good idea. Separate WAIT FOR LSN statement called in
the middle of transaction looks problematic for me. Imagine we have RR
isolation and already acquired the snapshot. Then out snapshot can
block applying wal records, which we are waiting for. That would be
implicit deadlock. It would be nice to evade such deadlocks by
design.

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