From: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
---|---|
To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
Subject: | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Date: | 2025-07-18 08:57:23 |
Message-ID: | CAJpy0uCH=JGtF+fJo6gpmg+i6cZJmc77u3aMKFc+xxMTt82m-A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 17, 2025 at 3:06 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Wed, Jun 18, 2025 at 3:23 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
> >
> > On Wed, Jun 18, 2025 at 2:39 PM Bertrand Drouvot
> > <bertranddrouvot(dot)pg(at)gmail(dot)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?
>
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). Similarly when a user is trying to
> drop the last logical slot via pg_drop_replication_slot, we will allow
> it only with the force option. This should ensure that the user is
> aware of the consequences of dropping the last slot.
>
One concern I have is regarding the default setting of
'force_slot_drop' . I assume the default value of this new DROP-SUB
argument will be 'false' to prevent customers from inadvertently
dropping the last slot on the publisher. But, would this be
acceptable, considering that users may have DROP-SUBSCRIPTION commands
in their scripts which would suddenly stop dropping slot now? OTOH, if
we keep the default as 'true', users might overlook changing it to
'false' when dropping the last subscription, and thus not solving any
purpose.
thanks
Shveta
From | Date | Subject | |
---|---|---|---|
Next Message | Andrei Lepikhov | 2025-07-18 09:31:01 | Re: track generic and custom plans in pg_stat_statements |
Previous Message | Nazir Bilal Yavuz | 2025-07-18 08:57:07 | Re: Improve error reporting in 027_stream_regress test |