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

From Andres Freund
Subject Re: ssl tests aren't concurrency safe due to get_free_port()
Date
Msg-id 20221123012607.pwfyln6ovjhzxlos@awork3.anarazel.de
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
Hi,

On 2022-11-22 10:57:41 -0500, Andrew Dunstan wrote:
> On 2022-11-20 Su 14:05, Andres Freund wrote:
> >> If it works ok I will backpatch in couple of days.
> > +1
> Done.

While looking into a weird buildfarm failure ([1]), I noticed this:

# Checking port 62707
Use of uninitialized value $pid in scalar chomp at
/mnt/resource/bf/build/grassquit/REL_11_STABLE/pgsql.build/../pgsql/src/test/perl/PostgresNode.pmline 1247.
 
Use of uninitialized value $pid in addition (+) at
/mnt/resource/bf/build/grassquit/REL_11_STABLE/pgsql.build/../pgsql/src/test/perl/PostgresNode.pmline 1248.
 

This isn't related the failure afaics. I think it's happening for all runs on
all branches on my host. And also a few other animals [2].

Not quite sure how $pid ends up uninitialized, given the code:
    # see if someone else has or had a reservation of this port
    my $pid = <$portfile>;
    chomp $pid;
    if ($pid +0 > 0)

Greetings,

Andres Freund


[1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=grassquit&dt=2022-11-22%2016%3A33%3A57

The main symptom is
# Running: pg_ctl -D
/mnt/resource/bf/build/grassquit/REL_11_STABLE/pgsql.build/src/bin/pg_ctl/tmp_check/t_003_promote_standby2_data/pgdata
promote
waiting for server to promote....
pg_ctl: control file appears to be corrupt

[2]
https://buildfarm.postgresql.org/cgi-bin/show_stage_log.pl?nm=peripatus&dt=2022-11-23%2000%3A20%3A13&stg=pg_ctl-check



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: More efficient build farm animal wakeup?
Next
From: John Naylor
Date:
Subject: Re: Prefetch the next tuple's memory during seqscans