Extending USE_MODULE_DB to more test suite types
От | Noah Misch |
---|---|
Тема | Extending USE_MODULE_DB to more test suite types |
Дата | |
Msg-id | 20190401135213.GE891537@rfd.leadboat.com обсуждение исходный текст |
Ответы |
Re: Extending USE_MODULE_DB to more test suite types
Re: Extending USE_MODULE_DB to more test suite types |
Список | pgsql-hackers |
Some buildfarm runs have failed like this: ============== dropping database "pl_regression" ============== ERROR: database "pl_regression" is being accessed by other users DETAIL: There is 1 other session using the database. Affected runs: axolotl │ PLCheck-C │ REL9_5_STABLE │ 2015-08-21 19:29:19 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2015-08-21%2019:29:19 axolotl │ PLCheck-C │ REL9_6_STABLE │ 2017-03-16 17:43:16 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=axolotl&dt=2017-03-16%2017:43:16 mandrill │ PLCheck-C │ HEAD │ 2017-05-13 17:14:12 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2017-05-13%2017:14:12 tern │ PLCheck-C │ HEAD │ 2017-09-05 20:45:17 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=tern&dt=2017-09-05%2020:45:17 mandrill │ PLCheck-C │ HEAD │ 2017-11-15 13:34:12 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2017-11-15%2013:34:12 mandrill │ PLCheck-en_US.ISO8859-1 │ REL_10_STABLE │ 2018-03-15 05:24:41 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=mandrill&dt=2018-03-15%2005:24:41 frogfish │ TestModulesCheck-en_US.utf8 │ REL_11_STABLE │ 2019-01-29 01:32:51 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=frogfish&dt=2019-01-29%2001:32:51 hornet │ PLCheck-C │ REL_11_STABLE │ 2019-01-29 01:52:29 │ https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=hornet&dt=2019-01-29%2001:52:29 I can reproduce that reliably by combining "make -C src/pl installcheck" with this hack: proc_exit(int code) { + pg_usleep(7000000); This happens because dropdb()'s call to CountOtherDBBackends() waits up to 5s for the database to become vacant. If the last plpython test backend takes more than 5s to exit, the pltcl suite fails. Most test suites are unaffected, thanks to USE_MODULE_DB=1 in the buildfarm script. However, PL suites ignore USE_MODULE_DB. So do the three src/test/modules directories that contain no C code and define $(REGRESS). Isolation suites, too, ignore USE_MODULE_DB. I would like to fix this as follows. When MODULES and MODULE_big are both unset, instead of using a constant string, derive the database name from the first element of $(REGRESS) or $(ISOLATION). I considered $(EXTENSION), but src/test/modules/commit_ts does not set it. $(REGRESS) and $(ISOLATION) are robust; in their absence, a directory simply won't invoke pg_regress to drop and/or create a database. I considered introducing a TESTDB_SUFFIX variable that src/test/modules directories could define, but that felt like needless flexibility. Treat src/pl in a similar fashion. With the attached patch, installcheck-world and check-world no longer reuse any database name in a given postmaster. Next, I'll mail this buildfarm client patch, after which any non-MSVC, v9.5+ (due to ddc2504) buildfarm run would no longer reuse any database name in a given postmaster: --- a/run_build.pl +++ b/run_build.pl @@ -1677 +1677,2 @@ sub make_pl_install_check - @checklog = run_log("cd $pgsql/src/pl && $make installcheck"); + my $cmd = "cd $pgsql/src/pl && $make USE_MODULE_DB=1 installcheck"; + @checklog = run_log($cmd); I plan to back-patch the PostgreSQL patch, to combat buildfarm noise. Perhaps someone has test automation that sets USE_MODULE_DB and nonetheless probes the exact database name "pl_regression", but I'm not too worried. The original rationale for USE_MODULE_DB, in commit ad69bd0, was to facilitate pg_upgrade testing. Folks using "make installcheck-world" to populate a cluster for pg_upgrade testing will see additional test coverage, which may cause additional failures. I'm fine with that, too.
Вложения
В списке pgsql-hackers по дате отправления: