On Thu, Sep 3, 2026 at 10:54 AM shveta malik <[email protected]> wrote: > > On Thu, Sep 3, 2026 at 9:22 AM Nisha Moond <[email protected]> wrote: > > I agree with the idea of patch. But the patch can be improved. Before > this patch, slot creation happened after the conflict was found. Now > it happens unconditionally. So every call to FindConflictTuple() now > allocates a slot and immediately tears it down. So most of the cases > which are ocnflict-free now will do slot-allocation. I feel this can > be optimized. >
Good point, agree.
> Suggestion:
>
> retry:
> if (ExecCheckIndexConstraints(...))
> {
> if (*conflictslot)
> ExecDropSingleTupleTableSlot(*conflictslot);
> *conflictslot = NULL;
> return false;
> }
>
> if (*conflictslot == NULL)
> *conflictslot = table_slot_create(rel, NULL);
>
Adopted in v2, attached.
--
Thanks,
Nisha
v2-0001-Avoid-re-creating-the-conflict-slot-on-retry-in-F.patch
Description: Binary data
v2-0002-TAP-test-for-FindConflictTuple-buffer-pin-leak.patch
Description: Binary data
