Re: [BUGS] Old row version in hot chain become visible after a freeze
От | Michael Paquier |
---|---|
Тема | Re: [BUGS] Old row version in hot chain become visible after a freeze |
Дата | |
Msg-id | CAB7nPqR73SHUrc6rnWJKGWUCjGiAmTpNLb6bc3T0gkRJa4Bh9g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Old row version in hot chain become visible after a freeze (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [BUGS] Old row version in hot chain become visible after a freeze
Re: [BUGS] Old row version in hot chain become visible after a freeze |
Список | pgsql-bugs |
On Tue, Sep 5, 2017 at 9:44 PM, Michael Paquier <michael.paquier@gmail.com> wrote: > As the portion doing vacuum freeze is the one blowing up, I think that > it is possible to extract an isolation test and include it in the > patch with repro.sql as the initialization phase. Indeed, I have been able to reduce that to an isolation test which crashes with a rate of 100% if assertions are enabled. I have also spent a couple more hours looking at the proposed patch and eye-balling the surrounding code, and my suggestion about heap_tuple_needs_freeze() is proving to be wrong. So I am arriving at the conclusion that your patch is taking the right approach to skip freezing completely if the tuple is not to be removed yet if it is for vacuum either DEAD or RECENTLY_DEAD. I am adding as well in CC Álvaro and Andres, who reworked tuple freezing in 3b97e682 a couple of years back for 9.3. Could you look more at the bug and the attached patch? It does not fundamentally change from what has been proposed first, just did the following: - Updated set of comments that incorrectly assumed that only DEAD tuples should have freeze skipped. - Added isolation test for the failure. An entry has been added in the next open CF to track this problem. This should not fall into the cracks! -- Michael -- 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 по дате отправления: