On Thu, Sep 3, 2026 at 2:36 PM shveta malik <[email protected]> wrote: > > On Thu, Sep 3, 2026 at 1:03 PM Hayato Kuroda (Fujitsu) > <[email protected]> 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
