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 20230331231300.4kkrl44usvy2pmkv@awork3.anarazel.de
Whole thread Raw
In response to Re: regression coverage gaps for gist and hash indexes  (Alexander Lakhin <exclusion@gmail.com>)
Responses Re: regression coverage gaps for gist and hash indexes
List pgsql-hackers
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.

For the former I first wrote it in contrib/btree_gist. But that would mean the
recovery side isn't exercised via 027_stream_regress.sql. So I rewrote it to
use point instead, which is a tad more awkward, but...

For now I left the new tests in their own files. But possibly they should be
in gist.sql and hash_index.sql respectively?


As I also wrote at the top of the tests, we can't easily verify that
killtuples pruning has actually happened, nor guarantee that concurrent
activity doesn't prevent it (e.g. autovacuum having a snapshot open or
such). At least not without loosing coverage of WAL logging / replay. To make
it more likely I added them as their own test group.


I don't know if we want the tests in this form, but I do find them useful for
now.


Greetings,

Andres Freund

Attachment

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Data is copied twice when specifying both child and parent table in publication
Next
From: Justin Pryzby
Date:
Subject: Re: zstd compression for pg_dump