| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | vignesh C <vignesh21(at)gmail(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: pg_upgrade and logical replication[ |
| Date: | 2023-11-14 00:22:17 |
| Message-ID: | ZVK9uePiX5Qsla-_@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)paquier(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2023-11-14 00:32:56 | Re: pgsql: doc: fix wording describing the checkpoint_flush_after GUC |
| Previous Message | Andres Freund | 2023-11-14 00:17:38 | Re: Requiring recovery.signal or standby.signal when recovering with a backup_label |