Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

I am a little bit confused. Here T1 and X are the same transaction?

Best regards,
--
Tatsuo Ishii
SRA OSS, Inc. Japan
English: http://www.sraoss.co.jp/index_en.php
Japanese:http://www.sraoss.co.jp

> Avoid spurious deadlocks when upgrading a tuple lock
>
> When two (or more) transactions are waiting for transaction T1 to release a
> tuple-level lock, and transaction T1 upgrades its lock to a higher level, a
> spurious deadlock can be reported among the waiting transactions when T1
> finishes. The simplest example case seems to be:
>
> T1: select id from job where name = 'a' for key share;
> Y: select id from job where name = 'a' for update; -- starts waiting for X
> Z: select id from job where name = 'a' for key share;
> T1: update job set name = 'b' where id = 1;
> Z: update job set name = 'c' where id = 1; -- starts waiting for X
> T1: rollback;
>
> At this point, transaction Y is rolled back on account of a deadlock: Y
> holds the heavyweight tuple lock and is waiting for the Xmax to be released,
> while Z holds part of the multixact and tries to acquire the heavyweight
> lock (per protocol) and goes to sleep; once X releases its part of the
> multixact, Z is awakened only to be put back to sleep on the heavyweight
> lock that Y is holding while sleeping. Kaboom.
>
> This can be avoided by having Z skip the heavyweight lock acquisition. As
> far as I can see, the biggest downside is that if there are multiple Z
> transactions, the order in which they resume after X finishes is not
> guaranteed.
>
> Backpatch to 9.6. The patch applies cleanly on 9.5, but the new tests don't
> work there (because isolationtester is not smart enough), so I'm not going
> to risk it.
>
> Author: Oleksii Kliukin
> Discussion: https://postgr.es/m/B9C9D7CD-EB94-4635-91B6-E558ACEC0EC3@hintbits.com
>
> Branch
> ------
> REL_11_STABLE
>
> Details
> -------
> https://git.postgresql.org/pg/commitdiff/85600b7b5da42c5166eb1188c173beb3cc356178
>
> Modified Files
> --------------
> src/backend/access/heap/README.tuplock | 10 ++
> src/backend/access/heap/heapam.c | 84 +++++++++---
> .../expected/tuplelock-upgrade-no-deadlock.out | 150 +++++++++++++++++++++
> src/test/isolation/isolation_schedule | 1 +
> .../specs/tuplelock-upgrade-no-deadlock.spec | 57 ++++++++
> 5 files changed, 281 insertions(+), 21 deletions(-)
>