Re: regression coverage gaps for gist and hash indexes

Hi,

On 2023-04-02 12:38:32 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On 2023-04-01 06:02:47 +0200, Drouvot, Bertrand wrote:
> >> +1 to put them in gist.sql and hash_index.sql.
>
> > Unfortunately it turns out that running them in a parallel group reliably
> > prevents cleanup of the dead rows, at least on my machine. Thereby preventing
> > any increase in coverage. As they need to run serially, I think it makes more
> > sense to keep the tests focussed and leave gist.sql and hash_index.sql to run
> > in parallel.
>
> If they have to run serially then that means that their runtime
> contributes 1-for-1 to the total runtime of the core regression tests,
> which is not nice at all.

Agreed, it's not nice. At least reasonably quick (74ms and 54ms on one run
here)...

> Can we move them to some other portion of our test suite, preferably one
> that's not repeated four or more times in each buildfarm run?

Not trivially, at least. Right now 027_stream_regress.pl doesn't run other
tests, so we'd not cover the replay portion if moved the tests to
contrib/btree_gist or such.

I wonder if we should have a test infrastructure function for waiting for the
visibility horizon to have passed a certain point. I think that might be
useful for making a few other tests robust...

Greetings,

Andres Freund