Re: pgsql: Fix WAL replay of locking an updated tuple
В списке pgsql-committers по дате отправления:
| От | 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 по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера