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 по дате отправления: