Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
From: Oleksii Kliukin <alexk@hintbits.com>
In-Reply-To: <20190615170133.GA28251@alvherre.pgsql>
Date: Sun, 16 Jun 2019 00:12:21 +0200
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5EF8408A-46E6-409A-96A7-DC2C27F36235@hintbits.com>
References: <20190615170133.GA28251@alvherre.pgsql>
To: =?utf-8?Q?=C3=81lvaro_Herrera?= <alvherre@2ndquadrant.com>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

> On 2019-Jun-14, Alvaro Herrera wrote:
>=20
>> 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.)
>=20
> 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.
>=20
> I'm still trying to form a case to exercise the case of =
skip_tuple_lock
> having the wrong lifetime.

Hm=E2=80=A6 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.

> 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.

Cheers,
Oleksii=