Re: TAP test started using meson, can get a tcp port already used by another test. - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: TAP test started using meson, can get a tcp port already used by another test.
Date
Msg-id a29b91e1-8efb-4695-a345-18f5b0f1d4b6@dunslane.net
Whole thread Raw
In response to TAP test started using meson, can get a tcp port already used by another test.  (Zharkov Roman <r.zharkov@postgrespro.ru>)
Responses Re: TAP test started using meson, can get a tcp port already used by another test.
List pgsql-hackers
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




pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Support NOT VALID / VALIDATE constraint options for named NOT NULL constraints
Next
From: Jim Jones
Date:
Subject: Re: XMLSerialize: version and explicit XML declaration