Re: Synchronous commit behavior during network outage

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Synchronous commit behavior during network outage
Дата
Msg-id 431a6032ff437950f04094185970f0292105b5f0.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Synchronous commit behavior during network outage  (Andrey Borodin <x4mmm@yandex-team.ru>)
Ответы Re: Synchronous commit behavior during network outage
Список 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 по дате отправления:

Предыдущее
От: Paul A Jungwirth
Дата:
Сообщение: Re: SQL:2011 application time
Следующее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Unbounded %s in sscanf