Hi! On Fri, Apr 3, 2020 at 9:51 PM Anna Akenteva <a.akent...@postgrespro.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
