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 b8f5d215-cd90-9ea3-88d8-03a2c864ebb1@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-11-02 We 15:09, Andrew Dunstan wrote:
> 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.
>
>
>

Updated with a couple of thinkos fixed.


cheers


andrew


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

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Fix proposal for comparaison bugs in PostgreSQL::Version
Next
From: "Jonathan S. Katz"
Date:
Subject: Re: heavily contended lwlocks with long wait queues scale badly