1
0
mirror of https://github.com/postgres/postgres.git synced 2025-05-08 07:21:33 +03:00

Handle table_complete_speculative's succeeded argument as documented.

For some reason both callsite and the implementation for heapam had
the meaning inverted (i.e. succeeded == true was passed in case of
conflict). That's confusing.

I (Andres) briefly pondered whether it'd be better to rename
table_complete_speculative's argument to 'bool specConflict' or such,
but decided not to. The 'complete' in the function name for me makes
`succeeded` sound a bit better.

Reported-By: Ashwin Agrawal, Melanie Plageman, Heikki Linnakangas
Discussion:
   https://postgr.es/m/CALfoeitk7-TACwYv3hCw45FNPjkA86RfXg4iQ5kAOPhR+F1Y4w@mail.gmail.com
   https://postgr.es/m/97673451-339f-b21e-a781-998d06b1067c@iki.fi
This commit is contained in:
Andres Freund 2019-05-14 12:11:26 -07:00
parent 08e2edc076
commit aa4b8c61d2
2 changed files with 2 additions and 2 deletions
src/backend

@ -282,7 +282,7 @@ heapam_tuple_complete_speculative(Relation relation, TupleTableSlot *slot,
HeapTuple tuple = ExecFetchSlotHeapTuple(slot, true, &shouldFree);
/* adjust the tuple's state accordingly */
if (!succeeded)
if (succeeded)
heap_finish_speculative(relation, &slot->tts_tid);
else
heap_abort_speculative(relation, &slot->tts_tid);

@ -556,7 +556,7 @@ ExecInsert(ModifyTableState *mtstate,
/* adjust the tuple's state accordingly */
table_complete_speculative(resultRelationDesc, slot,
specToken, specConflict);
specToken, !specConflict);
/*
* Wake up anyone waiting for our decision. They will re-check