Re: installcheck-world concurrency issues
От | Andres Freund |
---|---|
Тема | Re: installcheck-world concurrency issues |
Дата | |
Msg-id | 20221004183553.prhb6ue6zpdyuip6@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: installcheck-world concurrency issues (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: installcheck-world concurrency issues
|
Список | pgsql-hackers |
Hi, On 2022-10-04 17:05:40 +0900, Michael Paquier wrote: > 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? I think regress_* without a "namespace" is what's src/test/regress uses, so there's not really a need? > > 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? There's various isolation tests, including several in src/test/isolation, that use advisory locks. prepared_xacts.sql shouldn't be an issue, because it's scheduled in a separate group. > > 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. Thanks for checking. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: