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