Re: pg_recvlogical prints bogus error when interrupted
От | Michael Paquier |
---|---|
Тема | Re: pg_recvlogical prints bogus error when interrupted |
Дата | |
Msg-id | ZLear1uoWkLBbrZq@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pg_recvlogical prints bogus error when interrupted (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: pg_recvlogical prints bogus error when interrupted
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: