Re: [PATCH] Release replication slot on error in SQL-callable slot functions

Hi,

On Tue, Sep 22, 2026 at 4:35 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> As Amit and Chao Li reported upthread, if it happens, the slot is left
> behind while holding catalog_xmin. Without the v19 patch,
> only the backend who created the slot can drop it (non-assertion
> builds), or the slot drop hits assertion failure (on assertion
> builds), whether the logical slot is temp or persistent. With the
> patch, the persistent logical slot is dropped on the slot release
> whereas users would still need to drop the incomplete slot manually.
> Such slots are left behind while having confirmed_flush_lsn being
> NULL.
>
> If users use such a slot for logical decoding, it can decode partial
> transactions. Since confirmed_flush is invalid,
> CreateDecodingContext() starts with an invalid start_decoding_at, and
> as it's not in slot creation, the snapshot builder can restore a
> serialized snapshot and jump to the consistent state in the middle of
> a transaction that started before the slot's restart_lsn.

Thanks all for the thoughts. I moved the temporary slot discussion to
a new thread [1] so that this thread can move forward with the issue
reported here, a slot that stays acquired after a slot function's
error is caught by a PL/pgSQL exception block. The fix in v19 releases
the slot when that subtransaction aborts.

It covers persistent logical and physical slots for both creation and
non-creation failures, and temporary logical and physical slots for
non-creation failures. A persistent logical slot whose creation failed
gets dropped by that release, since it is still ephemeral. Temporary
slots whose creation failed are handled in the new thread.

Appreciate any further comments on the v19 patches posted upthread.

[1] https://postgr.es/m/CALj2ACXDsQhq0MFuyRfZ0BJT6F93CNQmG5iv%2BwDzKp%2BYyOGD%2BA%40mail.gmail.com

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com