Re: Table AM callback table_complete_speculative()'s succeeded argument is reversed

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Table AM callback table_complete_speculative()'s succeeded argument is reversed
Date: 2019-05-14 14:06:34
Message-ID: 3B7A84AE-B15E-47AE-B5F4-213A28CA22CC@anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On May 14, 2019 4:29:01 AM PDT, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>The 'succeeded' argument seems backwards here:
>
>> static void
>> heapam_tuple_complete_speculative(Relation relation, TupleTableSlot
>*slot,
>> uint32 spekToken, bool succeeded)
>> {
>> bool shouldFree = true;
>> HeapTuple tuple = ExecFetchSlotHeapTuple(slot, true, &shouldFree);
>>
>> /* 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);
>> }
>
>According to the comments, if "succeeded = true", the insertion is
>completed, and otherwise it's killed. It works, because the only caller
>
>is also passing the argument wrong.

Thanks for finding.

>Barring objections, I'll push the attached patch to fix that.

Please hold off - your colleagues found this before, and I worked on getting test coverage for the code. It's scheduled for commit together today. Unfortunately nobody looked at the test much...

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Bapat 2019-05-14 14:11:39 Re: [HACKERS] advanced partition matching algorithm for partition-wise join
Previous Message Bruce Momjian 2019-05-14 13:19:45 Re: PostgreSQL 12: Feature Highlights