Date: Sat, 15 Jun 2019 18:47:13 -0400
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Oleksii Kliukin <alexk@hintbits.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Message-ID: <20190615224713.GA9414@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <5EF8408A-46E6-409A-96A7-DC2C27F36235@hintbits.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On 2019-Jun-16, Oleksii Kliukin wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
> 
> > 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.
> 
> Hm… I think it was an oversight from my part not to give skip_lock_tuple the
> same lifetime as have_tuple_lock or first_time (also initializing it to
> false at the same time). Even if now it might not break anything in an
> obvious way, a backward jump to l3 label will leave skip_lock_tuple
> uninitialized, making it very dangerous for any future code that will rely
> on its value.

But that's not the danger ... with the current coding, it's initialized
to false every time through that block; that means the tuple lock will
never be skipped if we jump back to l3.  So the danger is that the first
iteration sets the variable, then jumps back; second iteration
initializes the variable again, so instead of skipping the lock, it
takes it, causing a spurious deadlock.

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