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

From Drouvot, Bertrand
Subject Re: regression coverage gaps for gist and hash indexes
Date
Msg-id 84834c1b-f5c8-06a4-9162-2a597c848067@gmail.com
Whole thread Raw
In response to Re: regression coverage gaps for gist and hash indexes  (Andres Freund <andres@anarazel.de>)
Responses Re: regression coverage gaps for gist and hash indexes  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Hi,

On 4/1/23 1:13 AM, Andres Freund wrote:
> Hi,
> 
> 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.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: WL_SOCKET_ACCEPT fairness on Windows
Next
From: Amit Kapila
Date:
Subject: Re: Minimal logical decoding on standbys