Re: Fix resource leak in FindConflictTuple() retry path

On Thu, Sep 3, 2026 at 2:36 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Thu, Sep 3, 2026 at 1:03 PM Hayato Kuroda (Fujitsu)
> <kuroda(dot)hayato(at)fujitsu(dot)com> wrote:
> >
> > Dear Nisha,
> >
> > Not sure, should we release a buffer pin if should_refetch_tuple() returns true?
> > I referred heapam_tuple_lock()/heap_lock_tuple(), they pin a buffer via ReadBuffer()
> > and transfers to a slot via ExecStorePinnedBufferHeapTuple().
> >
> > IIUC, ExecClearTuple() can release corresponding resources for the slot, so below
> > fix is enough.
> >
>
> IMO, ExecClearTuple() can resolve the problem of pinned buffers but it
> still leaves the other trivial problem behind that we keep allocating
> slots while one is enough, which when resued will release buffer pin
> in ExecStorePinnedBufferHeapTuple() -> tts_buffer_heap_store_tuple()
> implicitly.

+1

> Therefore, this alone might not be a better fix. But if we want to
> club it with the fix already provided by Nisha, that will help us
> releasing the pin a little earlier without relying on next
> table_tuple_lock() on same slot to do that implictly. That said, I
> don't see ExecClearTuple() called explicitly in the two similar
> functions in this file, RelationFindReplTupleByIndex() and
> RelationFindReplTupleSeq(); both of which reuse a single
> caller-provided slot across retries and rely purely on the implicit
> release-on-restore behavior.
>

I also agree not to make FindConflictTuple() the only one clearing explicitly.

--
Thanks,
Nisha