From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | pgsql-committers <pgsql-committers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f |
Date: | 2022-01-20 13:58:39 |
Message-ID: | 855583.1642687119@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> On Thu, Jan 20, 2022 at 10:29 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-01-20 14:01:33 | pgsql: Remove 'datlastsysoid'. |
Previous Message | Thomas Munro | 2022-01-20 11:34:34 | Re: pgsql: Test replay of regression tests, attempt II. |