| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, Peter Geoghegan <pg(at)bowt(dot)ie>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
| Subject: | Re: installcheck-world concurrency issues |
| Date: | 2022-10-04 08:05:40 |
| Message-ID: | YzvpVF+LjL78LV9W@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2022-10-04 08:15:13 | pid_t on mingw |
| Previous Message | Bharath Rupireddy | 2022-10-04 07:50:54 | Assorted fixes related to WAL files (was: Use XLogFromFileName() in pg_resetwal to parse position from WAL file) |