Re: Synchronous commit behavior during network outage
От | Andrey Borodin |
---|---|
Тема | Re: Synchronous commit behavior during network outage |
Дата | |
Msg-id | 5164FCCE-1E02-4DBD-8D85-BE572E2515C9@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Synchronous commit behavior during network outage (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Synchronous commit behavior during network outage
|
Список | pgsql-hackers |
> 3 июля 2021 г., в 23:44, Jeff Davis <pgsql@j-davis.com> написал(а): > > 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. SIGABRT is expected to generate a core dump, isn't it? Node failover is somewhat expected state in HA system. > > 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. In my experience SIGTERM coped fine so far. > 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. I think 2 GUCs is a better solution than 1 GUC disabling both cancelation and termination. It would be great if some other HA tool developers would chime in. Thanks! Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: