Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > > I think I found another bug in MaintainOldSnapshotTimeMapping(): if
> > > you make time jump by more than old_snapshot_threshold in one go, then
> > > the map gets cleared and then no early pruning or snapshot-too-old
> > > errors happen. That's why in 002_too_old.pl it currently advances
> > > time by 10 minutes twice, instead of 20 minutes once. To be
> > > continued.
> >
> > IMHO that doesn't seems to be a problem. Because even if we jump more
> > than old_snapshot_threshold in one go we don't clean complete map
> > right. The latest snapshot timestamp will become the headtimestamp.
> > So in TransactionIdLimitedForOldSnapshots if (current_ts -
> > old_snapshot_threshold) is still >= head_timestap then we can still do
> > early pruning.
>
> Right, thanks. I got confused about that, and misdiagnosed something
> I was seeing.
>
> Here's a new version:
>
> 0004: Instead of writing a new kind of TAP test to demonstrate
> snapshot-too-old errors, I adjusted the existing isolation tests to
> use the same absolute time control technique. Previously I had
> invented a way to do isolation tester-like stuff in TAP tests, which
> might be interesting but strange new perl is not necessary for this.
>
> 0005: Truncates the time map when the CLOG is truncated. Its test is
> now under src/test/module/snapshot_too_old/t/001_truncate.sql.
>
> These apply on top of Robert's patches, but the only dependency is on
> his patch 0001 "Expose oldSnapshotControl.", because now I have stuff
> in src/test/module/snapshot_too_old/test_sto.c that wants to mess with
> that object too.
>
> 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?

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com