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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Дата
Msg-id 4827.1560733813@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Ответы Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2019-Jun-16, Tom Lane wrote:
>> If you're going to push anything before tomorrow's wrap, please do it
>> *now* not later.  We're running out of time to get a full sample of
>> buildfarm results.

> Yeah, I had to bail out earlier today, so the only thing I'm confident
> pushing now is a revert.

Yeah, let's do that.  I don't want to risk shipping broken code.
We can try again for the next updates.

            regards, tom lane



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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock
Следующее
От: Michael Paquier
Дата:
Сообщение: nbtdesc.c and nbtpage.c are inconsistent withXLOG_BTREE_META_CLEANUP (11~)