Re: pg_upgrade and logical replication[

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: pg_upgrade and logical replication[
Дата
Msg-id ZVK9uePiX5Qsla-_@paquier.xyz
обсуждение исходный текст
Ответ на Re: pg_upgrade and logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: pg_upgrade and logical replication[  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Mon, Nov 13, 2023 at 04:02:27PM +0530, Amit Kapila wrote:
> On Mon, Nov 13, 2023 at 1:52 PM Michael Paquier <michael@paquier.xyz> wrote:
>> It seems to me that INIT cannot be relied on for a similar reason.
>> This state would be set for a new relation in
>> LogicalRepSyncTableStart(), and the relation would still be in INIT
>> state when creating the slot via walrcv_create_slot() in a second
>> transaction started a bit later.
>
> Before creating a slot, we changed the state to DATASYNC.

Still, playing the devil's advocate, couldn't it be possible that a
server crashes just after the slot got created, then restarts with
max_logical_replication_workers=0?  This would keep the catalog in a
state authorized by the upgrade, still leak a replication slot on the
publication side if the node gets upgraded.  READY in the catalog
seems to be the only state where we are guaranteed that there is no
origin and no slot remaining around.
--
Michael

Вложения

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

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Requiring recovery.signal or standby.signal when recovering with a backup_label
Следующее
От: Andres Freund
Дата:
Сообщение: Re: pgsql: doc: fix wording describing the checkpoint_flush_after GUC