Re: ssl tests aren't concurrency safe due to get_free_port()

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: ssl tests aren't concurrency safe due to get_free_port()
Date: 2023-05-02 05:57:05
Message-ID: 23b40753-5926-a575-68a4-98549fae9d1b@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 25.04.23 12:27, Peter Eisentraut wrote:
> These patches have affected pgxs-using extensions that have their own
> TAP tests.
>
> The portlock directory is created at
>
>     my $build_dir = $ENV{top_builddir}
>       || $PostgreSQL::Test::Utils::tmp_check ;
>     $portdir ||= "$build_dir/portlock";
>
> but for a pgxs user, top_builddir points into the installation tree,
> specifically at $prefix/lib/pgxs/.
>
> So when running "make installcheck" for an extension, we either won't
> have write access to that directory, or if we do, then it's still not
> good to write into the installation tree during a test suite.
>
> A possible fix is
>
> diff --git a/src/Makefile.global.in b/src/Makefile.global.in
> index 5dacc4d838..c493d1a60c 100644
> --- a/src/Makefile.global.in
> +++ b/src/Makefile.global.in
> @@ -464,7 +464,7 @@ rm -rf '$(CURDIR)'/tmp_check && \
>  $(MKDIR_P) '$(CURDIR)'/tmp_check && \
>  cd $(srcdir) && \
>     TESTDIR='$(CURDIR)' PATH="$(bindir):$(CURDIR):$$PATH" \
> -   PGPORT='6$(DEF_PGPORT)' top_builddir='$(top_builddir)' \
> +   PGPORT='6$(DEF_PGPORT)' top_builddir='$(CURDIR)' \
>     PG_REGRESS='$(top_builddir)/src/test/regress/pg_regress' \
>     $(PROVE) $(PG_PROVE_FLAGS) $(PROVE_FLAGS) $(if
> $(PROVE_TESTS),$(PROVE_TESTS),t/*.pl)
>  endef

Any thoughts on this? I would like to get this into the upcoming minor
releases.

Note that the piece of code shown here is only applicable to PGXS, so
given that that is currently broken, this "can't make it worse".

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Yurii Rashkovskii 2023-05-02 06:15:39 Re: [PATCH] Support % wildcard in extension upgrade filenames
Previous Message Peter Geoghegan 2023-05-02 04:19:11 Re: Overhauling "Routine Vacuuming" docs, particularly its handling of freezing