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 | CAB7nPqSRbohi9L0EH4QMZMPYT_mZ3YQg0xf5QUxvdSmixd7-tQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUGS] Old row version in hot chain become visible after a freeze (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: [BUGS] Old row version in hot chain become visible after a freeze
|
Список | pgsql-bugs |
On Wed, Sep 6, 2017 at 7:40 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > Otherwise, we risk marking the page as all-frozen, and it would be > skipped by vacuum. If we never come around to HOT-pruning the page, a > non-permanent xid (or a multixact? not sure that that can happen; > probably not) would linger unnoticed and cause a DoS condition later > ("cannot open file pg_clog/1234") when the tuple header is read. Yes, you are definitely right here. On Wed, Sep 6, 2017 at 10:27 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > Another thing is that if you're going through heap_copy_data, the tuple > is only checked for DEAD, not RECENTLY_DEAD. Maybe there is no bug here > but I'm not sure yet. Not sure to what you are referring here. Perhaps heap_prune_chain()? It seems to me that it does the right thing. > I attach the patch as I have it now -- mostly comment tweaks, but also > the change to not mark page as all-frozen when we skip freezing a > recently read tuple. I also renamed the test case, because I think it > may be possible to reach the problem code without involving a multixact. > Haven't tried too hard though. +test: freeze-the-dead This one has made me smile.. +++ b/src/test/isolation/expected/freeze-the-dead.spec @@ -0,0 +1,101 @@ +Parsed test spec with 2 sessions The test fails as expected/ files need to be named with .out, not .spec. -- 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 по дате отправления: