Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, alexk(at)hintbits(dot)com
Subject: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Date: 2019-06-15 16:25:39
Message-ID: 21723.1560615939@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Alvaro Herrera 2019-06-15 17:01:33 Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Previous Message Alvaro Herrera 2019-06-15 03:43:37 Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-06-15 17:01:33 Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Previous Message Alvaro Herrera 2019-06-15 16:09:50 assertion at postmaster start