Re: Issues with ON CONFLICT UPDATE and REINDEX CONCURRENTLY - Mailing list pgsql-hackers

On 2025-Dec-19, Mihail Nikalayeu wrote:

> Hello, Álvaro and others!
> 
> Attached version feels stable enough so far - 20 builds in a row on
> all CI variants (including 3 BSD) - no failures so far.

Hello Mihail, thanks for the time spent on this new test.  I have pushed
it now after some editorializing, just to make the code a bit easier to
read.  I did lose the test numbering, but added some note() lines for
each subtest so that somebody reading through the output would be able
to match a failure to each subtest.

I also changed to create a bunch of tables at the start of the file
which are reused for each subtest (via truncate), instead of dropping
and recreating them all the time.  This reduces the test runtime (not
insignificantly, some 25% I think, though I didn't spend time measuring
it very scientifically).

I'm not sure what the implications are about marking this no longer used
in installcheck.  I think it means some buildfarm animals may no longer
run it, if they're configured to only do installcheck.  It's a bit of a
bummer because potential loss of runs for the other files in this test
module.  Still, I'm not crying about it.


Incidentally, I think it would be great to use Test::More subtests with
these tests (because then the failures would be more clearly attributed
to a specific part of the test file), and I experimented with that, but
it turns out that Meson doesn't like the subtest output (see [1] for
more on this topic).  I tried to make it accept TAP version 14 (which is
supposed to make it understand subtests) by adding things like "TAP
version 14" at the start of the output, which is supposed to be the way
to achieve this, but it seems to go completely ignored and I didn't want
to waste time trying to figure out why.  The note()s should achieve more
or less the same, in not so elegant a manner.

[1] https://postgr.es/m/20220224150033.5lql2lkiv7y5kkme@alap3.anarazel.de

> Also, tests designed in a way to fail fast if something is going wrong
> + log some debug information in that case (active queries with its
> states).

Nice.  I forgot to actually verify that this works as intended before
pushing.

> Special tricks to handle forced-cache release builds included too.

I ran the test in this mode, and it passes fine.

> Also, there is a test which "breaks" all the fixes - to ensure the
> test actually catches them, not intended to be committed of course.

I played with this; each change makes some of the subtests fail in a
pretty obvious way, and the failures are easy to track down in the
output log file.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"But static content is just dynamic content that isn't moving!"
                http://smylers.hates-software.com/2007/08/15/fe244d0c.html