Re: [BUGS] Old row version in hot chain become visible after a freeze
От | Alvaro Herrera |
---|---|
Тема | Re: [BUGS] Old row version in hot chain become visible after a freeze |
Дата | |
Msg-id | 20170928134400.mm74ldkisk4z5dkl@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [BUGS] Old row version in hot chain become visible after a freeze ("Wong, Yi Wen" <yiwong@amazon.com>) |
Ответы |
Re: [BUGS] Old row version in hot chain become visible after a freeze
|
Список | pgsql-bugs |
Wong, Yi Wen wrote: > 2) Flip the order of HeapTupleHeaderIsHeapOnly(tuple) and HeapTupleHeaderIsHotUpdated(tuple). This is merely a > microoptimization on a non-performance critical path because HeapOnly is a broader condititon than HotUpdated :-) Actually, is this correct? AFAICS, IsHeapOnly refers to the *new* version of the tuple in a HOT update, whereas IsHotUpdated refers to the *old* version. We surely must never freeze a IsHotUpdated tuple (because that would bring a dead tuple back to life, which is the bug at hand), but what is the argument against freezing a IsHeapOnly tuple? I think the way this test is written comes from some fuzzy thinking -- somebody (probably me) copied the test from lazy_scan_heap, but that routine has two different reasons for each of those two conditions (one is merely an optimization, the other is necessary for correctness). But in the spot we're patching, one of them is wrong. I could observe that this bug causes xids older than cutoff xid to remain in xmax occasionally with that test in place. Removing the "IsHeapOnly" part and keeping only IsHotUpdated makes that go away. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: