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: <855583.1642687119@sss.pgh.pa.us>
References: <E1nAIWI-0006et-HW@gemulon.postgresql.org>
 <CA+hUKGKV6fOHvfiPt8=dOKzvswjAyLoFoJF1iQXMNpi7+hD1JQ@mail.gmail.com>
 <855583.1642687119@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 20 Jan 2022 08:58:39 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <867289.1642689136.1@sss.pgh.pa.us>
Date: Thu, 20 Jan 2022 09:32:16 -0500
Message-ID: <867290.1642689136@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/867290.1642689136%40sss.pgh.pa.us>
Precedence: bulk

I wrote:
> 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.

Oh, wait --- the case that is failing is after 017_shm.pl has
intentionally kill -9'd a postmaster, so that its pidfile is
left behind.  The next attempted start fails on shmem id
conflict, but it doesn't remove the old pidfile, and then
the code I added to sub start erroneously picks that up
as a live postmaster PID.

Seems like we need to do 'kill 0' on the PID we get from
the file to verify that there's really a postmaster there.
(I wonder how well that works on Windows?  perlport claims
it does, but ...)

I fear I still don't have the whole story though because
per this theory it should fail everywhere, yet it doesn't.

			regards, tom lane