Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: shveta malik <shveta.malik@gmail.com>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
Masahiko Sawada <sawada.mshk@gmail.com>, Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2025-07-17T09:37:42Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix regression test failure when wal_level is set to minimal.
- 0de5f0d869d1 19 (unreleased) landed
-
Toggle logical decoding dynamically based on logical slot presence.
- 67c20979ce72 19 (unreleased) landed
-
Disallow server start with sync_replication_slots = on and wal_level < logical.
- 12da45742cfd 19 (unreleased) cited
On Thu, Jul 17, 2025 at 3:06 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Wed, Jun 18, 2025 at 3:23 PM shveta malik <shveta.malik@gmail.com> wrote: > > > > On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot > > <bertranddrouvot.pg@gmail.com> wrote: > > > > > > Hi, > > > > > > On Tue, Jun 10, 2025 at 02:00:55PM -0700, Masahiko Sawada wrote: > > > > > > > > > 0001 patch allows us to create a logical slot without WAL reservation. > > > > > > Thanks for the patch and sorry to be late in this conversation. > > > > > > The thing that worry me a bit with this is that that could be easy to attempt > > > to use the slot "by mistake" and then (as a consequence) trigger WAL reservation > > > by mistake on the primary. I think that this mistake is more likely to happen > > > with a logical slot as compared to a physical slot. > > > > > > > Yes, agreed. Another concern is the possibility of someone > > intentionally using it and associating it with a subscription. If the > > subscription is later dropped, it could also cause the slot to be > > removed. > > > > IIUC, your main concern here is that the last slot on > primary/publisher could be dropped unintentionally by the user leading > to invalidating the logical slots on any physical-standby connected > with publisher, right? > > What if we make DROP SUBSCRIPTION fail if it can lead to removal of > the last slot on publisher and allow DROP to succeed when the > subscription's drop_slot_force (a new subscription option) is set? > Now, users can still be allowed to Drop the subscription, if it > disassociates the subscription from the slot by using method explained > in docs [1] (See Notes section). > Forgot to specify link. Done now [1]. [1] - https://www.postgresql.org/docs/devel/sql-dropsubscription.html -- With Regards, Amit Kapila.