Re: upgrades in row-level locks can deadlock
Alvaro Herrera <alvherre@2ndquadrant.com>
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Oleksii Kliukin <alexk@hintbits.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-06-13T18:00:14Z
Lists: pgsql-hackers
On 2019-Jun-13, Oleksii Kliukin wrote: > Makes sense. For the symmetry I have included those that perform lock > upgrades in one session and those that doesn’t, while the other sessions > acquire locks, do updates or deletes. For those that don’t upgrade locks the > test checks that the locks are acquired in the correct order. Thanks for the updated patch! I'm about to push to branches 9.6-master. It applies semi-cleanly (only pgindent-maturity whitespace conflicts). The [pg11 version of the] patch does applies to 9.5 cleanly ... but the isolation test doesn't work, because isolationtester was not smart enough back then. Since there have been no previous reports of this problem, and to avoid pushing untested code, I'm going to refrain from back-patching there. My guess is that it should work ... In 9.4 there are quite some severe conflicts, because 27846f02c176 was not back-patched there. (The bug number "#8470" still floats in my memory from time to time. Shudder) -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Commits
-
Avoid spurious deadlocks when upgrading a tuple lock
- 8b21b416ed62 12.0 landed
- 5246d3e79103 11.5 landed
- 0ba35c7c9f8e 9.6.15 landed
- 0772d8a00eb8 10.10 landed
- de87a084c0a5 12.0 landed
- cb2398d8069e 9.6.14 landed
- 85600b7b5da4 11.4 landed
- 14a91a8fc279 10.9 landed