Re: pg_upgrade and logical replication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: vignesh C <vignesh21@gmail.com>, Peter Smith <smithpb2250@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
Julien Rouhaud <rjuju123@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-13T10:32:27Z
Lists: pgsql-hackers
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. > > However, if we have a failure after > the transaction that created the slot commits, then we'd have an INIT > relation in the catalog that got committed *and* a slot related to it > lying around. > I don't think this can happen otherwise this could be a problem even without an upgrade after restart. -- With Regards, Amit Kapila.
Commits
-
pg_upgrade: Retrieve subscription count more efficiently.
- 73de50e13e39 17.0 landed
- 364509a2e7f9 18.0 landed
-
Fix random failure in 004_subscription.
- 677a45c4ae16 17.0 landed
-
Fix 004_subscription.pl to allow its usage in --link mode.
- f17529b71097 17.0 landed
-
Allow upgrades to preserve the full subscription's state.
- 9a17be1e244a 17.0 landed
-
Prevent startup of logical replication launcher during pg_upgrade
- 7021d3b17664 17.0 landed