Re: heapam_tuple_complete_speculative : remove unnecessary tuple fetch - Mailing list pgsql-hackers

From Xuneng Zhou
Subject Re: heapam_tuple_complete_speculative : remove unnecessary tuple fetch
Date
Msg-id CABPTF7XJ3gv+R+4+eGMX=ggN1m6bD7=rbxDi-cHN+GJUV5jSYg@mail.gmail.com
Whole thread
In response to Re: heapam_tuple_complete_speculative : remove unnecessary tuple fetch  (Japin Li <japinli@hotmail.com>)
List pgsql-hackers
On Tue, Mar 24, 2026 at 8:16 PM Japin Li <japinli@hotmail.com> wrote:
>
>
> > 在 2026年3月24日,14:57,Chao Li <li.evan.chao@gmail.com> 写道:
> >
> > Hi,
> >
> > While reviewing another patch, I noticed this:
> > ```
> > static void
> > heapam_tuple_complete_speculative(Relation relation, TupleTableSlot *slot,
> >                                  uint32 specToken, bool succeeded)
> > {
> >    bool        shouldFree = true;
> >    HeapTuple    tuple = ExecFetchSlotHeapTuple(slot, true, &shouldFree); // <== tuple is not used
> >
> >    /* adjust the tuple's state accordingly */
> >    if (succeeded)
> >        heap_finish_speculative(relation, &slot->tts_tid);
> >    else
> >        heap_abort_speculative(relation, &slot->tts_tid);
> >
> >    if (shouldFree)
> >        pfree(tuple);
> > }
> > ```
> >
> > In this function, tuple is not used at all, so there seems to be no need to fetch it, and shouldFree is thus not
neededeither. 
> >
> > This appears to have been there since 5db6df0c011, where the function was introduced. It looks like a copy-pasto
fromthe previous function, heapam_tuple_insert_speculative(), which does need to fetch and possibly free the tuple. 
> >
> > I tried simply removing ExecFetchSlotHeapTuple(), and "make check" still passes. But I may be missing something, so
I’dlike to confirm. 
> >
> > The attached patch just removes the unused tuple and shouldFree from this function. As touching the file, I also
fixeda typo in the file header comment. 
>
> Makes sense! All test cases passed with make check-world.
>

+1, looks like a simple copy-pasto and the patch LGTM.

--
Best,
Xuneng



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Initial COPY of Logical Replication is too slow
Next
From: David Rowley
Date:
Subject: Re: eliminate xl_heap_visible to reduce WAL (and eventually set VM on-access)