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