Hi,
On Wed, Sep 16, 2026 at 2:02 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> > Sawada-san, does that mean that on the back branches, even for the
> > case where the concerned subtransaction is committing while the slot
> > is still held (a scenario we don't know can happen), we would release
> > the slot and clean up MyReplicationSlotSubId? Is my understanding
> > correct?
>
> I don't think we should release the slot at subxact commit. I think
> it's better to leave it to the caller as it might release the slot
> afterward. Another problem is that nothing tests this case.
>
> Please refer to the attached patch that can be applied on v16 patch
> and implements my idea. It adds additional regression tests too.
Thanks for sharing the diff. I apologize for going back and forth on
the subtransaction commit hand-off. After looking at it, here is what
I have.
The slot acquired in a subtransaction gets cleaned up only if that
subtransaction is aborted, which is the reported bug and easily
reachable from SQL today.
MyReplicationSlotSubId is not a stale value within the transaction but
the owner's subtransaction id. However, across transactions it becomes
stale and can get reused, so it is reset at the subtransaction commit
path, preventing MyReplicationSlotSubId from going stale for users
carrying the slot across transactions (if any). In core code, the
owning subtransaction always releases the slot before it ends, and the
release clears the id. No hand-off, no warning on subtransaction
commit.
Please find the attached patch for HEAD. I dropped the two unnecessary
header file inclusions added in the diff but otherwise took it as-is.
If it looks good, I can prepare the patches for all supported
branches.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
