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