On Mon, Apr 1, 2019 at 9:52 AM Noah Misch <n...@leadboat.com> wrote: > > 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.
Excellent. Extending use of USE_MODULE_DB has been on my list of things to do. I'll add the buildfarm patch right away. It should be harmless before these changes are made. cheers andrew -- Andrew Dunstan https://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
