From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Cc: alexk@hintbits.com
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Date: Sat, 15 Jun 2019 13:01:33 -0400
Message-ID: <20190615170133.GA28251@alvherre.pgsql> (raw)
In-Reply-To: <20190615034337.GA24560@alvherre.pgsql>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: alvherre@2ndquadrant.com, tgl@sss.pgh.pa.us, pgsql-hackers@lists.postgresql.org, alexk@hintbits.com
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
In-Reply-To: <20190615170133.GA28251@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox