| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Jeff Davis <pgsql(at)j-davis(dot)com> |
| Cc: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server |
| Date: | 2026-07-09 07:17:02 |
| Message-ID: | CAA4eK1+tyYSpPxMBy1974kjivuGeR7YY=yopwRGrK3+vCTysdg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 9, 2026 at 12:50 AM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
>
> On Wed, 2026-07-08 at 10:29 +0530, Amit Kapila wrote:
> > Okay, I see your point and we can make it return early when slot_name
> > is NONE. However, do we need to consider a case where users want to
> > manually manage the subscription's main slot, so it uses
> > slot_name=NONE? I mean users want to manually maintain the lifecycle
> > of the slot and due to that even during the CREATE SUBSCRIPTION, it
> > uses the specified slot_name instead of the default. But still
> > tablesync slots need to be removed in such a case as those are
> > internally created.
>
> The problem is that we are overloading slot_name=NONE, and as you point
> out, it can mean multiple things.
>
> Can we just have DROP SUBSCRIPTION ... FORCE or DROP SUBSCRIPTION ...
> NOCONNECT? That allows the user to clearly express their intent at the
> time of the drop, rather than guessing from the state of the
> subscription.
>
That sounds like an appropriate solution or we can use (connect =
false) option as well a way to indicate NOCONNECT.
> If it's too late to do that for 19,
>
I feel it is late for 19.
we should probably just make the
> code match the documentation and don't try to connect if
> slot_name=NONE. In most ordinary cases that would not cause a problem,
> you'd have to have slot_name=NONE and also drop the subscription before
> the table syncs finish.
>
Yeah, we can do this but if we want to change this behaviour in the
next version, isn't it better to tweak the doc wording as:"After that,
DROP SUBSCRIPTION will not attempt to drop the subscription's own
replication slot. It may still connect to the publisher to drop
internally-created table synchronization slots if some table
synchronization was left unfinished; if the publisher is unreachable,
those slots (and the main slot, if it still exists) must be dropped
manually.". I think in most cases where we need this is where the
publisher is not available or the network is broken and in those
cases, the current code still works and won't leave any tablesync
slots.
--
With Regards,
Amit Kapila.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2026-07-09 07:18:16 | Re: implement CAST(expr AS type FORMAT 'template') |
| Previous Message | Kyotaro Horiguchi | 2026-07-09 07:15:42 | Re: Fix data checksum processing for temp relations and dropped databases |