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 | 20170912124136.kgasny22tjf7btdj@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: [BUGS] Old row version in hot chain become visible after a freeze (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-bugs |
Michael Paquier wrote: > On Tue, Sep 12, 2017 at 5:22 PM, Alvaro Herrera <alvherre@alvh.no-ip.org> wrote: > > Michael Paquier wrote: > >> On Mon, Sep 11, 2017 at 11:01 PM, Alvaro Herrera > >> <alvherre@alvh.no-ip.org> wrote: > >> > (I also threw in a small sleep between heap_page_prune and > >> > HeapTupleSatisfiesVacuum while testing, just to widen the problem window > >> > to hopefully make any remaining problems more evident.) > >> > >> I am understanding that you mean heap_prepare_freeze_tuple here > >> instead of heap_page_prune. > > > > Hmm ... no, I meant adding a sleep after the page is pruned, before > > HeapTupleSatisfiesVacuum call that determines the action with regards to > > freezing. > > Well, I have tested both. With the test case of Dan adding a sleep > after calling HeapTupleSatisfiesVacuum() helped in increasing the > window. Of course feel free to correct me. OK, great, thanks for testing. > > I bet those are multixact values rather than garbage. You should see > > HEAP_XMAX_IS_MULTI in t_infomask in those cases, and the values should > > be near NextMultiXactId (make sure to checkpoint if you examine with > > pg_controldata; I think it's easier to obtain it from shmem. Or you > > could just use pg_get_multixact_members()). > > Yes, you're right. That's the case. So I guess that I don't have much > complains about the patch as presented. Thanks for the confirmation. -- Á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 по дате отправления: