Re: pg_upgrade and logical replication[

Поиск
Список
Период
Сортировка
От Amit Kapila
Тема Re: pg_upgrade and logical replication[
Дата
Msg-id CAA4eK1JngEayzHaxfDM8LbOUL3=tBE47oq_NPaJ+xJJ9Xs1wDQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_upgrade and logical replication[  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Tue, Nov 14, 2023 at 5:52 AM Michael Paquier <michael@paquier.xyz> wrote:
>
> 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,
>

The state should be DATASYNC by that time and I don't think that is an
authorized state by upgrade.

--
With Regards,
Amit Kapila.



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

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: Is this a problem in GenericXLogFinish()?
Следующее
От: Nathan Bossart
Дата:
Сообщение: typo in fallback implementation for pg_atomic_test_set_flag()