update table error when gp_enable_global_deadlock_detector is on

[my-ship-it]

Reproduce the problem:

  pull cbdb code and start a demo cluster.

    
  set gp_enable_global_deadlock_detector

gpconfig -c gp_enable_global_deadlock_detector -v true

restart the cluster

gpstop -ra

create table and update or delete data

CREATE TABLE news ( id SERIAL8 NOT NULL PRIMARY KEY, a text, b text, c text );

INSERT INTO news(a, b, c) SELECT md5(random()::text), md5(random()::text), md5(random()::text) from ( SELECT * FROM generate_series(1,300) AS id ) AS x;

get an error like below:

ubuntu=# delete from news where id = 11; ERROR: "news_pkey" is an index

[willmkonos]

Cloudberry Database 1.5.4+dev.4.g7f8ccb8f build 79345 commit:7f8ccb8 gpconfig -c gp_enable_global_deadlock_detector -v on gpstop -ra In financial systems, there are scenarios where financial clients perform update actions, and it can happen that multiple updates are attempted on the same ID simultaneously, leading to an error ：

create table mengde_0813(id int , name varchar(100) ) distributed by (id);

insert into mengde_0813 values(1,'11'); insert into mengde_0813 values(2,'22'); insert into mengde_0813 values(3,'33');

session1： begin; update mengde_0813 set name ='11111' where id =1 ;

session2: begin; update mengde_0813 set name ='11111' where id =1 ;

session1: commit;

session2: ERROR: tuple to be locked was already moved to another partition or segment due to concurrent update (seg1 [192.168.199.1:40000] pid=2720)

If this parameter is turned off, there will be no error, but the customer must need the function of row level lock