On Wed, Jul 19, 2023 at 01:46:02PM +0530, Bharath Rupireddy wrote: > Printing LSN on signal exit won't be correct - if signal is received > before cur_record_lsn gets assigned, we will be showing an old LSN if > it was previously assigned or invalid LSN if it wasn't assigned > previously. Signal arrival and processing are indeterministic, so we > can't always show the right info.
I think that there's an argument to be made because cur_record_lsn will be set before coming back to the beginning of the replay loop when a stop is triggered by a signal. > Instead, we can just be simple in the messaging without an lsn like > pg_receivewal. Anyway, I'm OK with simple for now as it looks that you don't feel about that either, and the patch is enough to fix the report of this thread. And one would get periodic information in --verbose mode depending the sync message frequency, as well. So, I have applied v6 after fixing two issues with it: - I have kept the reason as an argument of prepareToTerminate(), to be able to take advantage of the switch structure where compilers would generate a warning if adding a new value to StreamStopReason. - cur_record_lsn was not initialized at the beginning of StreamLogicalLog(), which is where the compiler complains about the case of receiving a signal before entering in the replay loop, after establising a connection. -- Michael
signature.asc
Description: PGP signature
