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: <20190615224713.GA9414@alvherre.pgsql>
Date: Tue, 18 Jun 2019 19:13:49 +0100
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers@lists.postgresql.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <DB0AA460-7962-4E8D-AC1A-958457DB6563@hintbits.com>
References: <20190615224713.GA9414@alvherre.pgsql>
To: =?utf-8?Q?=C3=81lvaro_Herrera?= <alvherre@2ndquadrant.com>
Precedence: bulk

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

> On 2019-Jun-16, Oleksii Kliukin wrote:
>=20
>> Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>=20
>>> 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.
>>=20
>> 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.
>=20
> 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.

Sorry, I was confused, as I was looking only at
=
https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommitdiff;h=3Dd=
e87a084c0a5ac927017cd0834b33a932651cfc9

without taking your subsequent commit that silences compiler warnings at
=
https://git.postgresql.org/gitweb/?p=3Dpostgresql.git;a=3Dcommitdiff;h=3D3=
da73d6839dc47f1f47ca57974bf28e5abd9b572
into consideration. With that commit, the danger is indeed in resetting =
the
skip mechanism on each jump and potentially causing deadlocks.

Cheers,
Oleksii=