Hi Bruce, Tom
>The backstory on this is at the cited Red Hat bug ... apparently the OP
>decided I was clueless and he needed to consult some real authorities.
Oh come on, I'm very sure you both are good guys and know what you are
doing, none of us is ignorant bastard :)
Decided to open case here too, because of simple reason - maybe someone had
same issue, or knows how pg_upgrade works (in details) better than me,
because I am clueless.
This is test DB and I can erase it, but I'm very sure there's something
wrong in upgrade process - this is what I want to be solved.
Now, we can open a bottle of whiskey and go back to the problem:
1. I didn't run postmaster before/during pg_upgrade, it was never invoked
manually in this process
2. There is no pid file AFTER application is stopped, but looks like it's
there while pg_upgrade is running - strace showed that and there is no need
to run FAM to verify that
I don't know how pg_upgrade works, looks like it's trying to start
postmaster, which runs, postmaster.pid is created, then postmaster fails
stop or needs some more time bedore pg_upgrade is checking it's pid. That's
what I see.
So, is pg_upgrade starting postmaster? If yes, then when (at which step)
and why pid file check is done. That's all what we all want to know, right?
Best regards,
George Machitidze
On Sat, Jan 19, 2013 at 8:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.us> writes:
> > Why is a clean shutdown important? If the server crashed, we would have
> > committed transactions in the WAL files which are not transfered to the
> > new server, and would be lost.
>
> > I am hesistant to even start such an old server because pg_upgrade never
> > modifies the old server. Even starting it in that case would be
> > modifying it.
>
> I'm not really following this logic. If the old cluster was in a
> crashed state, why would we not expect that starting a postmaster would
> be the best (only) way to repair the damage and make everything good
> again? Isn't that exactly what the user would have to do anyway? What
> other action would you expect him to take instead?
>
> (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.
>
> regards, tom lane
>
