Re: fixing old_snapshot_threshold's time->xid mapping

On Mon, Apr 20, 2020 at 8:02 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> On Mon, Apr 20, 2020 at 12:29 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > 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?

I think it's enough to check SELECT EVERY(all_visible) FROM
pg_visibility_map('sto1'::regclass). I realised that
src/test/module/snapshot_too_old is allowed to install
contrib/pg_visibility with EXTRA_INSTALL, so here's a new version to
try that idea. It extends sto_using_select.spec to VACUUM and check
the vis map at key times. That allows us to check that early pruning
really happens once the snapshot becomes too old. There are other
ways you could check that but this seems quite "light touch" compared
to something based on page inspection.

I also changed src/test/module/snapshot_too_old/t/001_truncate.pl back
to using Robert's contrib/old_snapshot extension to know the size of
the time/xid map, allowing an introspection function to be dropped
from test_sto.c.

As before, these two apply on top of Robert's patches (or at least his
0001 and 0002).