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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: make -C src/test/isolation failure in index-killtuples due to btree_gist
Date: 2025-11-18 14:00:39
Message-ID: rsgolpgcheedmh62mhvrpbka4skgczw5x7gf3wjdzyye7mnm4m@uimvk3wrq5ni
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2025-11-18 14:01:00 Re: Speed up COPY FROM text/CSV parsing using SIMD
Previous Message Konstantin Knizhnik 2025-11-18 13:59:36 Re: Bug in amcheck?