Re: Lock mode in ExecMergeMatched() - Mailing list pgsql-hackers

From Dean Rasheed
Subject Re: Lock mode in ExecMergeMatched()
Date
Msg-id CAEZATCU9e9Ccbi70yNbCcF7xvZ+zrjiD0_6eEq2zEZA1p+707A@mail.gmail.com
Whole thread Raw
In response to Lock mode in ExecMergeMatched()  (Alexander Korotkov <aekorotkov@gmail.com>)
Responses Re: Lock mode in ExecMergeMatched()  (Dean Rasheed <dean.a.rasheed@gmail.com>)
List pgsql-hackers
On Fri, 10 Mar 2023 at 21:42, Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> I wonder why does ExecMergeMatched() determine the lock mode using
> ExecUpdateLockMode().  Why don't we use lock mode set by
> table_tuple_update() like ExecUpdate() does?  I skim through the
> MERGE-related threads, but didn't find an answer.
>
> I also noticed that we use ExecUpdateLockMode() even for CMD_DELETE.
> That ends up by usage of LockTupleNoKeyExclusive for CMD_DELETE, which
> seems plain wrong for me.
>
> The proposed change is attached.
>

That won't work if it did a cross-partition update, since it won't
have done a table_tuple_update() in that case, and updateCxt.lockmode
won't have been set. Also, when it loops back and retries, it might
execute a different action next time round. So I think it needs to
unconditionally use LockTupleExclusive, since it doesn't know if it'll
end up executing an update or a delete.

I'm currently working on a patch for bug #17809 that might change that
code though.

Regards,
Dean



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: pg_dump versus hash partitioning
Next
From: Tom Lane
Date:
Subject: Re: pg_dump versus hash partitioning