Re: BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve
От | Tom Lane |
---|---|
Тема | Re: BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve |
Дата | |
Msg-id | 14955.1358574423@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with
pg_upgrade/postgreql-setup fails - invalid status retrieve
|
Список | pgsql-bugs |
Bruce Momjian <bruce@momjian.us> writes: > On Sat, Jan 19, 2013 at 12:02:31AM -0500, Tom Lane wrote: >> In the meantime, I was wondering a bit why pg_upgrade looks at the >> postmaster.pid file at all. > The reason we check for postmaster.pid is so we can give the user a clue > about which postmaster is running. [ scratches head... ] I failed to detect any such clue in the error message it prints. Had you printed the PID from the file, or even better looked to see if that process was actually still alive, this argument would be reasonable. But pg_upgrade does neither of those, whereas if it had started a postmaster the postmaster would have done both of those things. > Also, we don't want to start on a non-clean shutdown, so the missing pid > file tells us it was clean. I agree that super paranoia is not unreasonable in pg_upgrade. But it would be useful to print something similar to what the backend prints, about checking whether PID N is still there and manually removing the lock file if not. Or (ahem) you could let the existing backend-side logic do that for you, rather than reimplementing that logic badly. Meanwhile I still have to figure out how come the postmaster.pid file is still there in the OP's case ... regards, tom lane
В списке pgsql-bugs по дате отправления: