Re: installcheck-world concurrency issues
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Peter Geoghegan <pg@bowt.ie>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Date: 2022-10-04T08:05:40Z
Lists: 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
Commits
-
tests: Rename conflicting role names
- d90aa68c96a8 14.21 landed
- aa2ec0403d0a 15.16 landed
- 6a20b04f0408 16.0 landed
-
tests: Restrict pg_locks queries in advisory_locks.sql to current database
- 81487c83bed9 12.21 landed
- f232d7c6827c 13.17 landed
- e750e413325e 14.14 landed
- 3981fd5869fc 15.9 landed
- c3315a7da57b 16.0 landed