Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve
От | Bruce Momjian |
---|---|
Тема | Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve |
Дата | |
Msg-id | 20130123215857.GA6657@momjian.us обсуждение исходный текст |
Ответы |
Re: Re: [BUGS] BUG #7815: Upgrading PostgreSQL from 9.1
to 9.2 with pg_upgrade/postgreql-setup fails - invalid status retrieve
|
Список | pgsql-hackers |
On Sat, Jan 19, 2013 at 09:56:48PM -0500, Bruce Momjian wrote: > > (But, at least with the type of packaging I'm using in Fedora, he would > > first have to go through a package downgrade/reinstallation process, > > because the packaging provides no simple scripted way of manually > > starting the old postgres executable, only the new one. Moreover, what > > pg_upgrade is printing provides no help in figuring out whether that's > > the next step.) > > > > I do sympathize with taking a paranoid attitude here, but I'm failing > > to see what advantage there is in not attempting to start the old > > postmaster. In the *only* case that pg_upgrade is successfully > > protecting against with this logic, namely there's-an-active-postmaster- > > already, the postmaster is equally able to protect itself. In other > > cases it would be more helpful not less to let the postmaster analyze > > the situation. > > > > > The other problem is that if the server start fails, how do we know if > > > the failure was due to a running postmaster? > > > > Because we read the postmaster's log file, or at least tell the user to > > do so. That report would be unambiguous, unlike pg_upgrade's. > > Attached is a WIP patch to give you an idea of how I am going to solve > this problem. This comment says it all: Attached is a ready-to-apply version of the patch. I continued to use postmaster.pid to determine if I need to try the start/stop test --- that allows me to know which servers _might_ be running, because a server start failure might be for many reasons and I would prefer not to suggest the server is running if I can avoid it, and the pid file gives me that. The patch is longer than I expected because the code needed to be reordered. The starting banner indicates if it a live check, but to check for a live server we need to start/stop the servers and we needed to know where the binaries are, and we didn't do that until after the start banner. I removed the 'check' line for binary checks, and moved that before the banner printing. postmaster_start also now needs an option to supress an error. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-hackers по дате отправления: