On 2023-Jan-18, Drouvot, Bertrand wrote: > The current calls are done that way: > > wait_for_replay_catchup called: > - 8 times with write LSN as an argument > - 1 time with insert LSN as an argument > - 16 times with flush LSN as an argument
> So it looks like that providing a node as a second argument > would not help for the wait_for_replay_catchup() case. ... unless we changed the calls that wait for reply that use write or insert so that they use flush instead. Surely everything should still work, right? Flushing would still occur, either right after the write (as the transaction commits) or ~200ms afterwards when WAL writer catches up to that point. I suppose this may fail to be true if there is some test that is specifically testing whether writing WAL without flushing works, which should rare enough, but if it does exist, in that one place we can use the underlying wait_for_catchup(). -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
