Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple
От | Alvaro Herrera |
---|---|
Тема | Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple |
Дата | |
Msg-id | 20171206162115.kdsd2fnipyswonir@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple
Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updated tuple Re: [HACKERS] [COMMITTERS] pgsql: Fix freezing of a dead HOT-updatedtuple |
Список | pgsql-committers |
I think you've done a stellar job of identifying what the actual problem was. I like the new (simpler) coding of that portion of HeapTupleSatisfiesVacuum. freeze-the-dead is not listed in isolation_schedule; an easy fix. I confirm that the test crashes with an assertion failure without the code fix, and that it doesn't with it. I think the comparison to OldestXmin should be reversed: if (!TransactionIdPrecedes(xmax, OldestXmin)) return HEAPTUPLE_RECENTLY_DEAD; return HEAPTUPLE_DEAD; This way, an xmax that has exactly the OldestXmin value will return RECENTLY_DEAD rather DEAD, which seems reasonable to me (since OldestXmin value itself is supposed to be still possibly visible to somebody). Also, this way it is consistent with the other comparison to OldestXmin at the bottom of the function. There is no reason for the "else" or the extra braces. Put together, I propose the attached delta for 0001. Your commit message does a poor job of acknowledging prior work on diagnosing the problem starting from Dan's initial test case and patch. I haven't looked at your 0002 yet. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Вложения
В списке pgsql-committers по дате отправления: