From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | shveta malik <shveta(dot)malik(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> |
Subject: | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Date: | 2025-07-18 09:33:01 |
Message-ID: | CAA4eK1JQOYj98=3+6hTR8z9Og+ANPyN=XX40oFSwpq1-F9TJAw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jul 18, 2025 at 2:27 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> 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?
>
That would only happen when users use this new idea of enabling
wal_level to 'logical' on the fly. I think the users having existing
setups with pub-sub would have kept the default wal_level to 'logical'
on publisher.
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Sutou Kouhei | 2025-07-18 09:49:12 | Re: Make COPY format extendable: Extract COPY TO format implementations |
Previous Message | Michael J. Baars | 2025-07-18 09:31:24 | Upgrade from Fedora 40 to Fedora 42, or from PostgreSQL 16.3 to PostgreSQL 16.9 |