On Mon, Apr 20, 2020 at 12:29 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > > On Mon, Apr 20, 2020 at 6:35 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Mon, Apr 20, 2020 at 11:24 AM Thomas Munro <thomas.mu...@gmail.com> > > wrote: > > > > > > On Sat, Apr 18, 2020 at 9:27 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > On Sat, Apr 18, 2020 at 11:47 AM Thomas Munro <thomas.mu...@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.
Okay, got your point. Can we try to implement some test functions that can just call visibilitymap_get_status function internally? I agree that we will have to pass the correct block number but that we can find using TID. Or for testing, we can create a very small relation that just has 1 block? -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
