Re: fixing old_snapshot_threshold's time->xid mapping - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: fixing old_snapshot_threshold's time->xid mapping
Date
Msg-id CA+hUKGLuJz96cov7f1Zj7Dc_fSgAPq59EQqL4unxA0ko1DjRaw@mail.gmail.com
Whole thread Raw
In response to Re: fixing old_snapshot_threshold's time->xid mapping  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: fixing old_snapshot_threshold's time->xid mapping  (Dilip Kumar <dilipbalaut@gmail.com>)
List pgsql-hackers
On Mon, Apr 20, 2020 at 6:35 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> >
> > On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
> > > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> > Is this an improvement?  I realise that there is still nothing to
> > actually verify that early pruning has actually happened.  I haven't
> > thought of a good way to do that yet (stats, page inspection, ...).
>
> Could we test the early pruning using xid-burn patch?  Basically,  in
> xid_by_minute we have some xids with the current epoch.  Now, we burns
> more than 2b xid and then if we try to vacuum we might hit the case of
> early pruning no.  Do you wnated to this case or you had some other
> case in mind which you wnated to test?

I mean I want to verify that VACUUM or heap prune actually removed a
tuple that was visible to an old snapshot.  An idea I just had: maybe
sto_using_select.spec should check the visibility map (somehow).  For
example, the sto_using_select.spec (the version in the patch I just
posted) just checks that after time 00:11, the old snapshot gets a
snapshot-too-old error.  Perhaps we could add a VACUUM before that,
and then check that the page has become all visible, meaning that the
dead tuple our snapshot could see has now been removed.



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: where should I stick that backup?
Next
From: Noah Misch
Date:
Subject: Re: 001_rep_changes.pl stalls