TAP test started using meson, can get a tcp port already used by another test.
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t51111psql -h localhost -U postgresBuilt from patchset v4 (message #4), July 27, 2026 at 10:09 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t51111_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t51111_4 && git checkout t51111_4Patchset v4 (message #4) is on t51111_4
Hello,
We running TAP tests which operates with a lot of instances. And some of
these tests randomly fail due "address already in use". It turned out
that the meson does not set environment variable MESON_BUILD_ROOT when
running the test() function [0]https://mesonbuild.com/Reference-manual_functions.html#test. As a result each test uses its own
"portlock" directory [1]https://github.com/postgres/postgres/blob/7202d72787d3b93b692feae62ee963238580c877/src/test/perl/PostgreSQL/Test/Cluster.pm#L172. The small TAP test 001_portlock_env_test.pl
shows the test environment variables. As we can see MESON_BUILD_ROOT is
really undefined.
Can we explicitly set the MESON_BUILD_ROOT environment variable when
running a test? With included patch for the src/tools/testwrap file,
each instance gets an unique TCP port.
Thanks!
Best regards, Roman Zharkov
[0]: https://mesonbuild.com/Reference-manual_functions.html#test
[1]: https://github.com/postgres/postgres/blob/7202d72787d3b93b692feae62ee963238580c877/src/test/perl/PostgreSQL/Test/Cluster.pm#L172
https://github.com/postgres/postgres/blob/7202d72787d3b93b692feae62ee963238580c877/src/test/perl/PostgreSQL/Test/Cluster.pm#L172
On 2025-02-21 Fr 3:58 AM, Zharkov Roman wrote:
Hello,
We running TAP tests which operates with a lot of instances. And some
of these tests randomly fail due "address already in use". It turned
out that the meson does not set environment variable MESON_BUILD_ROOT
when running the test() function [0]. As a result each test uses its
own "portlock" directory [1]. The small TAP test
001_portlock_env_test.pl shows the test environment variables. As we
can see MESON_BUILD_ROOT is really undefined.
Argh!! Meson strikes again. Apparently this is only set ... sometimes.
Can we explicitly set the MESON_BUILD_ROOT environment variable when
running a test? With included patch for the src/tools/testwrap file,
each instance gets an unique TCP port.
Seems reasonable. In the meantime you can do what the buildfarm client
does and explicitly set PG_TEST_PORT_DIR.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 2025-02-21 16:32, Andrew Dunstan wrote:
In the meantime you can do what the buildfarm client does and
explicitly set PG_TEST_PORT_DIR.
Thank you for the answer! We tried to set PG_TEST_PORT_DIR using the
'env' option and it works fine.
Best regards, Roman Zharkov
Hi,
On 2025-02-21 15:58:45 +0700, Zharkov Roman wrote:
We running TAP tests which operates with a lot of instances. And some of
these tests randomly fail due "address already in use". It turned out that
the meson does not set environment variable MESON_BUILD_ROOT when running
the test() function [0].
I don't think meson ever set MESON_BUILD_ROOT during tests, so afaict the
portlock logic just just never worked with meson?
As a result each test uses its own "portlock" directory [1]. The small TAP
test 001_portlock_env_test.pl shows the test environment variables. As we
can see MESON_BUILD_ROOT is really undefined.
I'm rather baffled this hasn't caused more problems...
I have recently seen a CI failure that looked like it likely was caused by
this. It was in a back branch, and I thought that was the explanation, due to
the portlock logic not yet existing. But the portlock logic is old enough, so
it likely was this.
But I would have expected many more errors.
Can we explicitly set the MESON_BUILD_ROOT environment variable when running
a test? With included patch for the src/tools/testwrap file, each instance
gets an unique TCP port.
I don't like that, feels like a "namespace violation" to set a MESON_*
variable, why not set the top_builddir or a dedicated variable?
And I don't think it should be done in testwrap, but to test_env in the
top-level meson.build.
Something like the attached?
Greetings,
Andres Freund
On 2025-02-21 Fr 10:50 AM, Andres Freund wrote:
Can we explicitly set the MESON_BUILD_ROOT environment variable when running
a test? With included patch for the src/tools/testwrap file, each instance
gets an unique TCP port.I don't like that, feels like a "namespace violation" to set a MESON_*
variable, why not set the top_builddir or a dedicated variable?And I don't think it should be done in testwrap, but to test_env in the
top-level meson.build.Something like the attached?
LGTM
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
Hi,
On 2025-02-21 11:04:49 -0500, Andrew Dunstan wrote:
On 2025-02-21 Fr 10:50 AM, Andres Freund wrote:
Can we explicitly set the MESON_BUILD_ROOT environment variable when running
a test? With included patch for the src/tools/testwrap file, each instance
gets an unique TCP port.I don't like that, feels like a "namespace violation" to set a MESON_*
variable, why not set the top_builddir or a dedicated variable?And I don't think it should be done in testwrap, but to test_env in the
top-level meson.build.Something like the attached?
LGTM
Thanks for the quick review!
For some reason perltidy moves the $ENV{top_builddir} into the line with the =
once there's only one \n||. Somewhat annoying.
Pushed.
And thanks for the report, Roman!
Greetings,
Andres
On 2025-02-21 Fr 11:49 AM, Andres Freund wrote:
Hi,
On 2025-02-21 11:04:49 -0500, Andrew Dunstan wrote:
On 2025-02-21 Fr 10:50 AM, Andres Freund wrote:
Can we explicitly set the MESON_BUILD_ROOT environment variable when running
a test? With included patch for the src/tools/testwrap file, each instance
gets an unique TCP port.I don't like that, feels like a "namespace violation" to set a MESON_*
variable, why not set the top_builddir or a dedicated variable?And I don't think it should be done in testwrap, but to test_env in the
top-level meson.build.Something like the attached?
LGTM
Thanks for the quick review!
For some reason perltidy moves the $ENV{top_builddir} into the line with the =
once there's only one \n||. Somewhat annoying.
I would probably eat the newline.
Pushed.
Thanks
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com