Horton

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

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org, alexk@hintbits.com
Date: 2019-06-15T17:01:33Z
Lists: pgsql-hackers 
On 2019-Jun-14, Alvaro Herrera wrote:

> I think there are worse problems here.  I tried the attached isolation
> spec.  Note that the only difference in the two permutations is that s0
> finishes earlier in one than the other; yet the first one works fine and
> the second one hangs until killed by the 180s timeout.  (s3 isn't
> released for a reason I'm not sure I understand.)

Actually, those behaviors both seem correct to me now that I look
closer.  So this was a false alarm.  In the code before de87a084c0, the
first permutation deadlocks, and the second permutation hangs.  The only
behavior change is that the first one no longer deadlocks, which is the
desired change.

I'm still trying to form a case to exercise the case of skip_tuple_lock
having the wrong lifetime.


The fact that both permutations behave differently, even though the
only difference is where s0 commits relative to the s3_share step, is an
artifact of our unusual tuple locking implementation.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Avoid spurious deadlocks when upgrading a tuple lock

  2. Revert "Avoid spurious deadlocks when upgrading a tuple lock"

  3. Silence compiler warning