Re: Lock mode in ExecMergeMatched()
От | Dean Rasheed |
---|---|
Тема | Re: Lock mode in ExecMergeMatched() |
Дата | |
Msg-id | CAEZATCU9e9Ccbi70yNbCcF7xvZ+zrjiD0_6eEq2zEZA1p+707A@mail.gmail.com обсуждение исходный текст |
Ответ на | Lock mode in ExecMergeMatched() (Alexander Korotkov <aekorotkov@gmail.com>) |
Ответы |
Re: Lock mode in ExecMergeMatched()
|
Список | 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 по дате отправления: