Re: Extending USE_MODULE_DB to more test suite types

On Mon, Apr 1, 2019 at 9:52 AM Noah Misch <noah(at)leadboat(dot)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