From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: pgsql-committers <pgsql-committers@lists.postgresql.org>
Subject: Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl
 start" f
In-reply-to: 
 <CA+hUKGKV6fOHvfiPt8=dOKzvswjAyLoFoJF1iQXMNpi7+hD1JQ@mail.gmail.com>
References: <E1nAIWI-0006et-HW@gemulon.postgresql.org>
 <CA+hUKGKV6fOHvfiPt8=dOKzvswjAyLoFoJF1iQXMNpi7+hD1JQ@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Fri, 21 Jan 2022 00:08:56 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <855582.1642687119.1@sss.pgh.pa.us>
Date: Thu, 20 Jan 2022 08:58:39 -0500
Message-ID: <855583.1642687119@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/855583.1642687119%40sss.pgh.pa.us>
Precedence: bulk

Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, Jan 20, 2022 at 10:29 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> TAP tests: check for postmaster.pid anyway when "pg_ctl start" fails.

> This seems to have caused some kind of problem for the 017_shm.pl test:

Hmm.  I think the problem is that poll_start() thinks it can just call
start() a second time after a failure.  If it wasn't a true failure
but a timeout, then _pid is now set and the second call complains.

I'm not entirely sure how that scenario worked before --- maybe
pg_ctl is not picky about whether the running postmaster is the
same one it started??

Anyway it seems like we need some less-fuzzy thinking in poll_start.
Haven't absorbed enough caffeine to decide what.

A possible band-aid to get rid of the buildfarm failures is to force
a higher PGCTLTIMEOUT during poll_start.

			regards, tom lane