Re: pg_recvlogical prints bogus error when interrupted

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tristan Partin <tristan(at)neon(dot)tech>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, andres(at)anarazel(dot)de, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_recvlogical prints bogus error when interrupted
Date: 2023-07-10 04:44:45
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Jul 06, 2023 at 10:29:10AM -0500, Tristan Partin wrote:
> On Thu Apr 27, 2023 at 12:54 AM CDT, Bharath Rupireddy wrote:
>> Why do we need both time_to_abort and ready_to_exit?
> I am trying to understand why we need both as well. Maybe I am missing
> something important :).

As StreamLogicalLog() states once it leaves its main loop because
time_to_abort has been switched to true, we want a clean exit. I
think that this patch is just a more complicated way to avoid doing
twice the operations done by prepareToTerminate(). So how about
moving the prepareToTerminate() call outside the main streaming loop
and call it when time_to_abort is true? Then, I would suggest to
change the keepalive argument of prepareToTerminate() to an enum able
to handle three values to log the reason why the tool is stopping: the
end of WAL, an interruption or a keepalive when logging. There are
two of them now, but we want a third mode for the signals.

> > /* It is not unexepected termination error when Ctrl-C'ed. */
> My only other comment is that it would be nice to have the word "an"
> before unexpected.

s/unexepected/unexpected/. Still, it seems to me that we don't need
this comment.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Drouvot, Bertrand 2023-07-10 05:05:30 Re: Autogenerate some wait events code and documentation
Previous Message Amit Kapila 2023-07-10 04:21:07 Re: doc: improve the restriction description of using indexes on REPLICA IDENTITY FULL table.