Re: pg_recvlogical prints bogus error when interrupted

On Wed, Jul 19, 2023 at 1:41 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> > 3. pg_log_info("end position %X/%X reached on signal", .... For
> > signal, end position is a bit vague wording and I think we can just
> > say pg_log_info("received interrupt signal, exiting"); like
> > pg_receivewal. We really can't have a valid stop_lsn for signal exit
> > because that depends on when signal arrives in the while loop. If at
> > all, someone wants to know the last received LSN - they can look at
> > the other messages that pg_recvlogical emits - pg_recvlogical:
> > confirming write up to 0/2BFFFD0, flush to 0/2BFFFD0 (slot myslot).
>
> + case STREAM_STOP_SIGNAL:
> + pg_log_info("received interrupt signal, exiting");
> + break;
>
> Still it is useful to report the location we have finished with when
> stopping on a signal, no? Why couldn't we use "lsn" here, aka
> cur_record_lsn?

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. Instead, we can just be simple in
the messaging without an lsn like pg_receivewal.

--
Bharath Rupireddy
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com