Re: pgsql: Fix WAL replay of locking an updated tuple

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: pgsql: Fix WAL replay of locking an updated tuple
Дата
Msg-id 20140227144745.GH28858@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: pgsql: Fix WAL replay of locking an updated tuple  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-committers
On 2014-02-27 09:41:03 -0500, Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> > Fix WAL replay of locking an updated tuple
>
> The test added by this patch certainly looks like it's backwards.
> Shouldn't you be clearing HOT_UPDATED only if the tuple is *not*
> XMAX_IS_LOCKED_ONLY?

If it's not XMAX_IS_LOCKED_ONLY, we're locking the last tuple in the
ctid chain, so there is no need for t_ctid to point anywhere. If it's
not, there are later tuples (which the locking backend can't see yet
because of its snapshot) but which haven't changed the key and thus only
have NO KEY UPDATE lock level.

The bug exactly was that the ctid chain was destroyed when there were
later tuples.

Greetings,

Andres Freund

--
 Andres Freund                       http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


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

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: pgsql: Fix WAL replay of locking an updated tuple
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: Remove dependency on database encoding in citext regression test