From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
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 12:25:39 -0400
Message-ID: <21723.1560615939@sss.pgh.pa.us> (raw)
In-Reply-To: <20190615034337.GA24560@alvherre.pgsql>
References: <20190615034337.GA24560@alvherre.pgsql>
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jun-14, Tom Lane wrote:
>> BTW, after looking around a bit I wonder if this complaint isn't
>> exposing an actual logic bug. Shouldn't skip_tuple_lock have
>> a lifetime similar to first_time?
> 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.)
Ugh.
> I don't think I'm going to have time to investigate this deeply over the
> weekend, so I think the safest course of action is to revert this for
> next week's set.
+1. This is an old bug, we don't have to improve it for this release.
regards, tom lane
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: tgl@sss.pgh.pa.us, alvherre@2ndquadrant.com, pgsql-hackers@lists.postgresql.org, alexk@hintbits.com
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
In-Reply-To: <21723.1560615939@sss.pgh.pa.us>
* 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