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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Дата
Msg-id 20190615034337.GA24560@alvherre.pgsql
обсуждение исходный текст
Ответы Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 2019-Jun-14, Tom Lane wrote:

> I wrote:
> >> Hm, I don't get that warning.  Does this patch silence it, please?
> 
> > Uh, no patch attached?  But initializing the variable where it's
> > declared would certainly silence it.
> 
> 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.)

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.

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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Speed up transaction completion faster after many relations areaccessed in a transaction
Следующее
От: David Rowley
Дата:
Сообщение: Re: Extracting only the columns needed for a query