Re: ssl tests aren't concurrency safe due to get_free_port() - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: ssl tests aren't concurrency safe due to get_free_port()
Date
Msg-id 0891f64a-d30f-a1b7-9d0c-e447684cd8cd@dunslane.net
Whole thread Raw
In response to Re: ssl tests aren't concurrency safe due to get_free_port()  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: ssl tests aren't concurrency safe due to get_free_port()
List pgsql-hackers
On 2022-10-17 Mo 10:59, Andrew Dunstan wrote:
> On 2022-10-04 Tu 01:39, Andrew Dunstan wrote:
>> On 2022-10-02 Su 12:49, Andres Freund wrote:
>>> 2) Use a lockfile containing a pid to protect the choice of a port within a
>>>    build directory. Before accepting a port get_free_port() would check if the
>>>    a lockfile exists for the port and if so, if the test using it is still
>>>    alive.  That will protect against racyness between multiple tests inside a
>>>    build directory, but won't protect against races between multiple builds
>>>    running concurrently on a machine (e.g. on a buildfarm host)
>>>
>>>
>> I think this is the right solution. To deal with the last issue, the
>> lockdir should be overrideable, like this:
>>
>>
>>   my $port_lockdir = $ENV{PG_PORT_LOCKDIR} || $build_dir;
>>
>>
>> Buildfarm animals could set this, probably to the global lockdir (see
>> run_branches.pl). Prior to that, buildfarm owners could do that manually.
>>
>>
> The problem here is that Cluster.pm doesn't have any idea where the
> build directory is, or even if there is one present at all.
>
> meson does appear to let us know that, however, with MESON_BUILD_ROOT,
> so probably the best thing would be to use PG_PORT_LOCKDIR if it's set,
> otherwise MESON_BUILD_ROOT if it's set, otherwise the tmp_check
> directory. If we want to backport to the make system we could export
> top_builddir somewhere.
>
>

Here's a patch which I think does the right thing.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

Attachment

pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: libpq support for NegotiateProtocolVersion
Next
From: Tom Lane
Date:
Subject: Re: Check SubPlan clause for nonnullable rels/Vars