public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Jeff Davis <[email protected]>
Cc: Hayato Kuroda (Fujitsu) <[email protected]>
Cc: Chao Li <[email protected]>
Cc: Zsolt Parragi <[email protected]>
Cc: Ajin Cherian <[email protected]>
Cc: PostgreSQL-development <[email protected]>
Subject: Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server
Date: Wed, 8 Jul 2026 10:29:15 +0530
Message-ID: <CAA4eK1KGixKGG9++zZ8BFGp+indVxaof_8DR=9hVrY8=a8erRg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CAFPTHDZk-eY1K6OGWhLSWJ0C7qncVQvaxUmBL2r69_1CiznfTA@mail.gmail.com>
<[email protected]>
<CAN4CZFMemmQaxs9qT8MW3u_xRXrOa9mtmyup3Nizwb0V_C1axw@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CAA4eK1+TQXHR50rtp6eKt1Ejj3ttCKoJj9R+tO_0M+mUi0U66A@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<OS9PR01MB12149873B1F63BDBB3E5012CAF5ED2@OS9PR01MB12149.jpnprd01.prod.outlook.com>
<CAA4eK1KW5vVQ29RXYagpUb5K8xP-PCKsOXD2spK4j7byrjed-g@mail.gmail.com>
<[email protected]>
On Tue, Jul 7, 2026 at 5:11 AM Jeff Davis <[email protected]> wrote:
>
> On Mon, 2026-06-29 at 10:07 +0530, Amit Kapila wrote:
> > On Wed, Jun 24, 2026 at 7:48 AM Hayato Kuroda (Fujitsu)
> > <[email protected]> wrote:
> > >
> > > I went through the 0003 patch. Apart from HINT message, I found
> > > that error code
> > > ERRCODE_CONNECTION_FAILURE is always used. Should we report the
> > > original errcode
> > > of the root cause?
> > >
> >
> > That could be marginally better but not sure if it is worth the
> > complexity. I have a few more points regarding 0003:
> > * Regarding the point: "we can't absorb every kind of error." In the
> > PG_CATCH, re-throw query-cancel / interrupt-class conditions (if
> > those
> > are possible) instead of swallowing them, otherwise a SIGINT during
> > ForeignServerConnectionString() becomes a silent successful DROP (for
> > slot_name=NONE) or a mislabeled connection error.
>
> The DROP SUBSCRIPTION documentation says that:
>
> "To proceed in this situation, first disable the subscription by
> executing ALTER SUBSCRIPTION ... DISABLE, and then disassociate it from
> the replication slot by executing ALTER SUBSCRIPTION ... SET (slot_name
> = NONE). After that, DROP SUBSCRIPTION will no longer attempt any
> actions on a remote host."
>
> But that stopped being true after commit ce0fdbfe97. There should be
> some kind of escape such that we can force a DROP SUBSCRIPTION to
> succeed without trying to connect to the remote host. And if we have
> that escape, then we don't need to overcomplicate this by using a
> subtransaction and trying to guess which errors are recoverable or not.
>
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. Actually, this best-case try to connect to
publisher works for such cases. I think this is mostly a theoretical
scenario because ideally these tablesync slots should be removed at
the end of tablesync especially when users are doing drop subscription
as part of planned operation, so we can as well rely on the document
as we are doing now.
--
With Regards,
Amit Kapila.
view thread (28+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Bug in ALTER SUBSCRIPTION ... SERVER / ... CONNECTION with broken old server
In-Reply-To: <CAA4eK1KGixKGG9++zZ8BFGp+indVxaof_8DR=9hVrY8=a8erRg@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox