An update deadlock bug
Hello everyone:
Recently I found a parallel update bug，The steps to recurrence are as follows:
1,create table t1(a int, b varchar(20));
insert into t1 values(generate_series(1,5), 'abc');
2, use pgbench to run parallel update:
pgbench -U postgres -p 5432 postgres -n -r -c 10 -j 1 -T 100 -P 1 -f test.sql
test.sql: update t1 set a = 123 where b = 'abc';
3, We will find "deadlock detected" in log file or terminal.
I want to figure out that if every update use sequence scan ,why deadlock happened?
I look forward to receiving your reply.
Thank you very much!
"=?gb18030?B?MTAyNA==?=" <453539222@qq.com> writes:
Recently I found a parallel update bug£¬The steps to recurrence are as follows:
1,create table t1(a int, b varchar(20));
insert into t1 values(generate_series(1,5), 'abc');
2, use pgbench to run parallel update:
pgbench -U postgres -p 5432 postgres -n -r -c 10 -j 1 -T 100 -P 1 -f test.sql
test.sql: update t1 set a = 123 where b = 'abc';
3, We will find "deadlock detected" in log file or terminal.
I don't see any bug here. You've got multiple clients all trying
to update the same set of rows in an unspecified order. It's
unsurprising that some of them sometimes arrive at the same pair of
rows in a different order.
I want to figure out that if every update use sequence scan ,why deadlock happened?
Even though they're all using seqscans, there will be different
updates committing at different instants, and the live rows and
available free space will soon become wildly scrambled. If you
are expecting that "all the plans are seqscans" means "all the
sessions will operate in lockstep", you're mistaken.
regards, tom lane