On 2022-May-28, Andrey Borodin wrote:
> And reverting d9d0762 does not fix the issue. I'm not sure if I'm observing some other problem here.
>
> v4 of a test not use pg_sleep() and fails with regular amcheck
> failure. Reverting d9d0762 fixes the test. Unless I execute the test
> for 1 million transactions, then it fail even with a revert...
>
> I suspect that v3 and v4 triggers different problems.
Hmm, the only failure I see with v4 is a deadlock of this sort:
2022-05-31 17:26:13.400 CEST [130375] 004_rc.pl ERROR: deadlock detected
2022-05-31 17:26:13.400 CEST [130375] 004_rc.pl DETAIL: Process 130375 waits for ShareLock on transaction 36108;
blockedby process 130372.
Process 130372 waits for ShareLock on transaction 36107; blocked by process 130375.
Process 130375: INSERT INTO tbl VALUES(random()*1000,0,0,0,now())
on conflict(i) do update set updated_at = now();
Process 130372: INSERT INTO tbl VALUES(random()*1000,0,0,0,now())
on conflict(i) do update set updated_at = now();
which is of course not very interesting.
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
<Schwern> It does it in a really, really complicated way
<crab> why does it need to be complicated?
<Schwern> Because it's MakeMaker.