Re: pg_recvlogical prints bogus error when interrupted - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_recvlogical prints bogus error when interrupted
Date
Msg-id ZLear1uoWkLBbrZq@paquier.xyz
Whole thread Raw
In response to Re: pg_recvlogical prints bogus error when interrupted  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: pg_recvlogical prints bogus error when interrupted  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On Wed, Jul 19, 2023 at 12:07:21PM +0530, Bharath Rupireddy wrote:
> 1. I don't think we need a stop_lsn variable, the cur_record_lsn can
> help if it's defined outside the loop. With this, the patch can
> further be simplified as attached v6.

Okay by me.

> 2. And, I'd prefer not to assume the stop_reason as signal by default.
> While it works for now because the remaining place where time_to_abort
> is set to true is only in the signal handler, it is not extensible, if
> there's another exit condition comes in future that sets time_to_abort
> to true.

Yeah, I was also wondering whether this should be set by the signal
handler in this case while storing the reason statically on a specific
sig_atomic_t.

> 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?

> 4. With v5, it was taking a while to exit after the first CTRL+C, see
> multiple CTRL+Cs at the end:
> ubuntu::~/postgres/inst/bin$ ./pg_recvlogical --slot=lsub1_repl_slot
> --file=lsub1.data --start --verbose
> pg_recvlogical: starting log streaming at 0/0 (slot lsub1_repl_slot)
> pg_recvlogical: streaming initiated
> pg_recvlogical: confirming write up to 0/0, flush to 0/0 (slot lsub1_repl_slot)
> pg_recvlogical: confirming write up to 0/2BFFFD0, flush to 0/2BFFFD0
> (slot lsub1_repl_slot)
> pg_recvlogical: confirming write up to 0/2BFFFD0, flush to 0/2BFFFD0
> (slot lsub1_repl_slot)
> pg_recvlogical: confirming write up to 0/2BFFFD0, flush to 0/2BFFFD0
> (slot lsub1_repl_slot)
> ^Cpg_recvlogical: end position 0/2867D70 reached on signal
> ^C^C^C^C^C^C^C^C^C^C^C^C
> ^C^C^C^C^C^C^C^C^C^C^C^C

Isn't that where we'd need to look at a long change but we need to
stop cleanly?  That sounds expected to me.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Önder Kalacı
Date:
Subject: Re: doc: improve the restriction description of using indexes on REPLICA IDENTITY FULL table.
Next
From: Bharath Rupireddy
Date:
Subject: Re: pg_recvlogical prints bogus error when interrupted