Re: installcheck-world concurrency issues - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: installcheck-world concurrency issues
Date
Msg-id YzvpVF+LjL78LV9W@paquier.xyz
Whole thread Raw
In response to installcheck-world concurrency issues  (Andres Freund <andres@anarazel.de>)
Responses Re: installcheck-world concurrency issues  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Oct 03, 2022 at 04:41:11PM -0700, Andres Freund wrote:
> There's a few further roles that seem to pose some danger goign forward:

I have never seen that myself, but 0001 is a nice cleanup.
generated.sql includes a user named "regress_user11".  Perhaps that's
worth renaming while on it?

> BTW, shouldn't src/test/modules/unsafe_tests use the PG_TEST_EXTRA mechanism
> somehow?  Seems not great to run it as part of installcheck-world, if we don't
> want to run it as part of installcheck.c

Indeed.

> A second issue I noticed is that advisory_lock.sql often fails, because the
> pg_locks queries don't restrict to the current database. Patch attached.

As in prepared_xacts.sql or just advisory locks taken in an installed
cluster?  Or both?

> I attached the meson patch as well, but just because I used it to to get to
> these patches.

I am still studying a lot of this area, but it seems like all the
spots requiring a custom configuration (aka NO_INSTALLCHECK) are
covered.  --setup running is working here with 0003.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file)
Next
From: Peter Eisentraut
Date:
Subject: pid_t on mingw