Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f
От | Tom Lane |
---|---|
Тема | Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f |
Дата | |
Msg-id | 855583.1642687119@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: pgsql: TAP tests: check for postmaster.pid anyway when "pg_ctl start" f
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: