Re: Synchronous commit behavior during network outage - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Synchronous commit behavior during network outage
Date
Msg-id 431a6032ff437950f04094185970f0292105b5f0.camel@j-davis.com
Whole thread Raw
In response to Re: Synchronous commit behavior during network outage  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Synchronous commit behavior during network outage  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
On Sat, 2021-07-03 at 14:06 +0500, Andrey Borodin wrote:
> > But until you've disabled sync rep, the primary will essentially be
> > down for writes whether using this new feature or not. Even if you
> > can
> > terminate some backends to try to free space, the application will
> > just
> > make new connections that will get stuck the same way.
> 
> Surely I'm talking about terminating postmaster, not individual
> backends. But postmaster will need to terminate each running query.
> We surely need to have a way to stop whole instance without making
> any single query. And I do not like kill -9 for this purpose.

kill -6 would suffice.

I see the point that you don't want this to interfere with an
administrative shutdown. But it seems like most shutdowns will need to
escalate to SIGABRT for cases where things are going badly wrong (low
memory, etc.) anyway. I don't see a better solution here.

I don't fully understand why you'd be concerned about cancellation but
not concerned about similar problems with termination, but if you think
two GUCs are important I can do that.

Regards,
    Jeff Davis






pgsql-hackers by date:

Previous
From: Paul A Jungwirth
Date:
Subject: Re: SQL:2011 application time
Next
From: Daniel Gustafsson
Date:
Subject: Re: Unbounded %s in sscanf