Re: Draft back-branch release notes are up

On Mon, Nov 9, 2026 at 9:37 PM Bertrand Drouvot
<bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
>
> On Mon, Nov 09, 2026 at 10:20:06AM -0500, Tom Lane wrote:
> > Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com> writes:
> > > Maybe we could shorten the sentence, something like:
> >
> > > "
> > > Users issuing ALTER SUBSCRIPTION ... SET (slot_name = ..., two_phase = true) must
> > > ensure that the replacement slot already has two_phase enabled, as the apply worker
> > > no longer enables it automatically.
> > > "
> >
> > Huh. That seems like a bug: you asked for two_phase = true and
> > didn't get it. I'm fine with an implementation restriction that
> > we won't change the two_phase property of an existing slot, but
> > shouldn't this command throw an error if what you asked for
> > doesn't match what the slot can do?
>
> The current documentation [1] says:
>
> "
> When altering the slot_name, the failover and two_phase property values of the
> named slot may differ from the counterpart failover and two_phase parameters
> specified in the subscription. When creating the slot, ensure the slot properties
> failover and two_phase match their counterpart parameters of the subscription.
> "
>
> So the possibility of such a mismatch is documented, although I agree it is not
> ideal.
>
> The original doc warning was added after a discussion [2] about failover, where
> we chose documenting the limitation over adjusting the replacement slot at every
> apply worker startup. The two_phase wording was added later because the same
> mismatch was already possible.
>
> I don't think we considered checking the replacement slot and reporting an error
> on a mismatch. That would require connecting to the publisher and inspecting the
> replacement slot, but it would certainly make the command less surprising.
>
> So, I agree that reporting an error on a mismatch would be better. Amit, what do
> you think? I can have a look at preparing a patch if we want to go that way.
>

We can try but I feel manually setting up slots and subscriptions
correctly is also the user's responsibility, otherwise, user can rely
on the internally managed slots. For example, for this case, we need
to establish connection and query slot's data from the publisher which
we normally don't do, also what if connect=false, do we still try to
connect? It may add new restrictions.

--
With Regards,
Amit Kapila.