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

From Bharath Rupireddy
Subject Re: pg_recvlogical prints bogus error when interrupted
Date
Msg-id CALj2ACXkTNdWXYVQxO1mJ5c37eh3=aZXAb0=eqp3O2qOdvJ-kg@mail.gmail.com
Whole thread Raw
In response to Re: pg_recvlogical prints bogus error when interrupted  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
List pgsql-hackers
On Mon, Oct 24, 2022 at 8:15 AM Bharath Rupireddy
<bharath.rupireddyforpostgres@gmail.com> wrote:
>
> On Fri, Oct 21, 2022 at 7:52 AM Kyotaro Horiguchi
> <horikyota.ntt@gmail.com> wrote:
> >
> > > +1. How about emitting a message like its friend pg_receivewal, like
> > > the attached patch?
> >
> > I'm not a fan of treating SIGINT as an error in this case. It calls
> > prepareToTerminate() when time_to_abort and everything goes fine after
> > then. So I think we should do the same thing after receiving an
> > interrupt.  This also does file-sync naturally as a part of normal
> > shutdown.  I'm also not a fan of doing fsync at error.
>
> I think the pg_recvlogical can gracefully exit on both SIGINT and
> SIGTERM to keep things simple.
>
> > > > I also then noticed that we don't fsync the output file in cases of errors -
> > > > that seems wrong to me? Looks to me like that block should be moved till after
> > > > the error:?
> > >
> > > How about something like the attached patch?
>
> The attached patch (pg_recvlogical_graceful_interrupt.text) has a
> couple of problems, I believe. We're losing prepareToTerminate() with
> keepalive true and we're not skipping pg_log_error("unexpected
> termination of replication stream: %s" upon interrupt, after all we're
> here discussing how to avoid it.
>
> I came up with the attached v2 patch, please have a look.

FWIW, I added it to CF - https://commitfest.postgresql.org/40/3966/.

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



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Code checks for App Devs, using new options for transaction behavior
Next
From: Nishant Sharma
Date:
Subject: [PROPOSAL] : Use of ORDER BY clause in insert.sql