Re: [patch] demote

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [patch] demote
Дата
Msg-id CA+TgmoaPsDysv4S1FYdgyJ3vubjByjBm7fSqiB=xNyj5ZtORTA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [patch] demote  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: [patch] demote  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Thu, Jun 18, 2020 at 12:55 PM Fujii Masao
<masao.fujii@oss.nttdata.com> wrote:
> Even with ASRO, the server restart is necessary and RO sessions are
> kicked out when demoting RO primary to a standby, i.e., during a clean
> switchover?

The ASRO patch doesn't provide a way to put a running server to be put
back into recovery, so yes, that is required, unless some other patch
fixes it so that it isn't. It wouldn't be better to find a way where
we never need to kill of R/O sessions at all, and I think that would
require all the machinery from the ASRO patch plus some more. If you
want to allow sessions to survive a state transition like this -
whether it's to a WAL-read-only state or all the way back to recovery
- you need a way to prevent further WAL writes in those sessions. Most
of the stuff that the ASRO patch does is concerned with that. So it
doesn't seem likely to me that we can just throw all that code away,
unless by chance somebody else has got a better version of the same
thing already. To go back to recovery rather than just to a read-only
state, I think you'd need to grapple with some additional issues that
patch doesn't touch, like some of the snapshot-taking stuff, but I
think you still need to solve all of the problems that it does deal
with, unless you're OK with killing every session.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [patch] demote
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [patch] demote