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

On 2020-03-27 04:15, Kartyshov Ivan wrote:
> Anna, feel free to work on this patch.

Ivan and I worked on this patch a bit more. We fixed the bugs that we 
could find and cleaned up the code. For now, we've kept both options: 
WAIT as a standalone statement and WAIT as a part of BEGIN. The new 
patch is attached.

The syntax looks a bit different now:

- WAIT FOR [ANY | ALL] event [, ...]
- BEGIN [ WORK | TRANSACTION ] [ transaction_mode [, ...] ] [ WAIT FOR 
[ANY | ALL] event [, ...]]
where event is one of:
     LSN value
     TIMEOUT number_of_milliseconds
     timestamp

Now, one event cannot contain both an LSN and a TIMEOUT. With such 
syntax, the behaviour seems to make sense. For the (default) WAIT FOR 
ALL strategy, we pick the maximum LSN and maximum allowed timeout, and 
wait for the LSN till the timeout is over. If no timeout is specified, 
we wait forever. If no LSN is specified, we just wait for the time to 
pass. For the WAIT FOR ANY strategy, it's the same but we pick minimum 
LSN and timeout.

There are still some questions left:
1) Should we only keep the BEGIN option, or does the standalone command 
have potential after all?
2) Should we change the grammar so that WAIT can be in any position of 
the BEGIN statement, not necessarily in the end? Ivan and I haven't come 
to a consensus about this, so more opinions would be helpful.
3) Since we added the "wait" attribute to TransactionStmt struct, do we 
need to add something to _copyTransactionStmt() / 
_equalTransactionStmt()?

-- 
Anna Akenteva
Postgres Professional:
The Russian Postgres Company
http://www.postgrespro.com