Re: Temporary slot leak when creation fails in a subtransaction

Hi,

On Tue, Sep 29, 2026 at 2:10 AM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> Kuroda-san informed me off-list that it applies atop PG19 patch shared
> in another thread. I will review.

Thanks. The v1 patch attached here was built on top of the v19 patch
from the other thread -
https://postgr.es/m/CALj2ACXtHqVRBb40OHXx1JAMnv-L%3D-PFU_nyk2aB%3D0wMgkpGOw%40mail.gmail.com.
Apologies for not being clear about that in the initial email.

> But one question: are we planning to push this fix too to PG19 and
> thus the patch is this way? And then later we can do it on HEAD, is
> that the plan?

Thanks Kuroda-san for sharing the resource owner (resowner) idea. But
I don't think it fits well here. A slot can outlive the
(sub)transaction that created it, in which case dropping it at the end
of that (sub)transaction with a resowner might complicate things. It
may not work for the walsender, which creates slots without a
transaction. It also requires duplicating or moving some of the slot
release code we have today in the shmem exit callback, sigsetjmp
blocks etc. into the resowner callback. Also, logical decoding
internally starts its own (sub)transactions, which makes the resowner
approach a bit harder. IMHO, that feels more invasive than the fix
needs, even on HEAD.

So I still prefer the backend-local flag from v1, for both HEAD and
the back branches. It also handles both logical and physical temporary
slots, which a few of the other approaches mentioned upthread don't.

While at it, I found another case. A persistent physical slot whose
creation fails is also left behind, with or without a subtransaction,
since release does not drop it. v1 does not handle that yet, but the
same flag can cover it. Another approach is to create them as
ephemeral first and persist them once creation succeeds, as logical
slots do. Although physical slot creation failures are rare, I think
it is better to handle them as well to make the creation failure fixes
complete.

Thoughts?

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