Re: pg_recvlogical prints bogus error when interrupted
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tristan Partin <tristan@neon.tech>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>, andres@anarazel.de, pgsql-hackers@postgresql.org
Date: 2023-07-10T04:44:45Z
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. -- Michael
Commits
-
Fix pg_recvlogical upon signal termination
- 47556a0013fa 17.0 landed