Re: regression coverage gaps for gist and hash indexes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: regression coverage gaps for gist and hash indexes
Date
Msg-id 20230402162434.ererf6b5bqcq2ogz@awork3.anarazel.de
Whole thread Raw
In response to Re: regression coverage gaps for gist and hash indexes  ("Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>)
Responses Re: regression coverage gaps for gist and hash indexes
List pgsql-hackers
Hi,

On 2023-04-01 06:02:47 +0200, Drouvot, Bertrand wrote:
> On 4/1/23 1:13 AM, Andres Freund wrote:
> > On 2023-03-31 17:00:00 +0300, Alexander Lakhin wrote:
> > > 31.03.2023 15:55, Tom Lane wrote:
> > > > See also the thread about bug #16329 [1].  Alexander promised to look
> > > > into improving the test coverage in this area, maybe he can keep an
> > > > eye on the WAL logic coverage too.
> > > 
> > > Yes, I'm going to analyze that area too. Maybe it'll take more time
> > > (a week or two) if I encounter some bugs there (for now I observe anomalies
> > > with gist__int_ops), but I will definitely try to improve the gist testing.
> > 
> > Because I needed it to verify the changes in the referenced patch, I wrote
> > tests exercising killtuples based pruning for gist and hash.
> > 
> 
> Thanks for the patch!
> 
> I did not looked at the detail but "just" checked that the coverage is now done.
> 
> And Indeed, when running "make check" + "027_stream_regress.pl":
> 
> I can see it moving from (without the patch):
> 
> function gistXLogDelete called 0 returned 0% blocks executed 0%
> function gistRedoDeleteRecord called 0 returned 0% blocks executed 0%
> function gistprunepage called 0 returned 0% blocks executed 0%
> function _hash_vacuum_one_page called 0 returned 0% blocks executed 0%
> 
> to (with the patch):
> 
> function gistXLogDelete called 9 returned 100% blocks executed 100%
> function gistRedoDeleteRecord called 5 returned 100% blocks executed 100% (thanks to 027_stream_regress.pl)
> function gistprunepage called 9 returned 100% blocks executed 79%
> function _hash_vacuum_one_page called 12 returned 100% blocks executed 94%
> 
> > For now I left the new tests in their own files. But possibly they should be
> > in gist.sql and hash_index.sql respectively?
> 
> +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.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Greg Stark
Date:
Subject: Re: Add "host" to startup packet
Next
From: Tom Lane
Date:
Subject: Re: Add "host" to startup packet