Re: Fix resource leak in FindConflictTuple() retry path

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.
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.

> ```
> --- a/src/backend/executor/execReplication.c
> +++ b/src/backend/executor/execReplication.c
> @@ -268,7 +268,10 @@ retry:
> PopActiveSnapshot();
>
> if (should_refetch_tuple(res, &tmfd))
> + {
> + ExecClearTuple(*conflictslot);
> goto retry;
> + }
> ```
>
> Best regards,
> Hayato Kuroda
> FUJITSU LIMITED
>