| From: | Nisha Moond <nisha(dot)moond412(at)gmail(dot)com> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, "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-16 10:18:46 |
| Message-ID: | CABdArM410Y+qXZA5MhFAnu_GnZdNmtSsM3CwPNCTkoZwqK+Tdg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 16, 2026 at 2:47 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Mon, Jul 13, 2026 at 11:21 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
> > On Sat, Jul 11, 2026 at 8:42 PM Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> > >
> > > On Thu, 2026-07-09 at 12:47 +0530, Amit Kapila wrote:
> > > > That sounds like an appropriate solution or we can use (connect =
> > > > false) option as well a way to indicate NOCONNECT.
> > >
> > > That doesn't have a separate state in the catalog, so DROP SUBSCRIPTION
> > > doesn't know that it was specified.
> > >
> >
> > I was imagining doing something what CREATE SUBSCRIPTION doc describes
> > for this option: "Specifies whether the CREATE SUBSCRIPTION command
> > should connect to the publisher at all.". I mean some sort of WITH
> > (connect = false) but on re-thinking, for DROP it is better to use a
> > clause like NOCONNECT instead of providing options. Anyway, we can
> > brainstorm on the exact syntax in a separate thread for this work.
> >
> > > > 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.".
> > >
> > > Right, we can make the documentation match the code instead of making
> > > the code match the documentation. I don't have a strong opinion which
> > > way to go. But the wording above is fine with me.
> > >
> >
> > Fair enough. So, I'll commit this to HEAD and backbaptch till PG14.
> >
>
> Here are patches for versions HEAD-to-17 and 16-to-14. Unless there
> are any comments or suggestions, I'll push these tomorrow.
>
Thanks for the patches. I verified both on their respective branches
(master through PG14).
The patches apply cleanly, and the doc builds successfully on all branches.
--
Thanks,
Nisha
| From | Date | Subject | |
|---|---|---|---|
| Next Message | shveta malik | 2026-07-16 10:32:14 | Re: Support EXCEPT for TABLES IN SCHEMA publications |
| Previous Message | Greg Burd | 2026-07-16 10:04:43 | Re: Tepid: selective index updates for heap relations |