On 2023-Mar-11, Alexander Korotkov 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 al
On 2023-Mar-13, Dean Rasheed wrote:
> I'm wondering now if it really matters what lock mode we use here. If
> the point of calling table_tuple_lock() after a concurrent update is
> detected is to prevent more concurrent updates, so that the retry is
> guaranteed to succeed, then wouldn't even Lock
> On Fri, 10 Mar 2023 at 21:42, Alexander Korotkov 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
On Fri, 10 Mar 2023 at 21:42, Alexander Korotkov 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 a
Hi!
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 f
