Re: make -C src/test/isolation failure in index-killtuples due to btree_gist - Mailing list pgsql-hackers

From Andres Freund
Subject Re: make -C src/test/isolation failure in index-killtuples due to btree_gist
Date
Msg-id rsgolpgcheedmh62mhvrpbka4skgczw5x7gf3wjdzyye7mnm4m@uimvk3wrq5ni
Whole thread Raw
In response to Re: make -C src/test/isolation failure in index-killtuples due to btree_gist  (Michael Paquier <michael@paquier.xyz>)
Responses Re: make -C src/test/isolation failure in index-killtuples due to btree_gist
List pgsql-hackers
Hi,

On 2025-11-18 08:40:46 +0900, Michael Paquier wrote:
> On Tue, Nov 18, 2025 at 08:31:41AM +0900, Michael Paquier wrote:
> > Hmm.  We should try to conclude over the benefit of TAP over
> > isolation, and merge both patches together if the consensus is towards
> > a TAP test.
> > 
> > The isolation test feels much cleaner to me in terms of clarity and
> > debugging output compared to the suggested TAP test as there are many
> > SQL sequences the test depends on.  Other opinions?
> 
> By the way, an extra argument in favor of an isolation test here: the
> proposed TAP tests only wants to make sure that replay is able to
> finish on a standby, we don't query it.

I think we should eventually extend the test to run amcheck etc on both
primary and standby.


> We are already doing the same in 027_stream_regress.pl for the main
> regression test suite, and we could expand this TAP test or add a new one
> that grabs the isolation test suite and runs it in a TAP test with a standby
> plugged.

I don't think we should add new things to 027_stream_regress, it's already one
of the two slowest tests and, at least for me, often the test that takes the
longest to complete in a testrun.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Konstantin Knizhnik
Date:
Subject: Re: Bug in amcheck?
Next
From: Andrew Dunstan
Date:
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD