Bruce Momjian <bruce@momjian.us> writes:
> On Fri, Jan 18, 2013 at 10:19:48PM +0000, giomac@gmail.com wrote:
>> https://bugzilla.redhat.com/show_bug.cgi?id=896161
>> Upgrading PostgreSQL from 9.1 to 9.2 with pg_upgrade/postgreql-setup fails
>> with invalid message "There seems to be a postmaster servicing the old
>> cluster". Looks like pg_upgrade is checking pid file too early without
>> waiting for master process to exit:
>>
>> open("/var/lib/pgsql/data-old/postmaster.pid", O_RDONLY) = 5
> How are you shutting down the postmaster? Are you use pg_ctl -w stop?
> If not, you have to wait for the server to actually shut down before
> starting pg_upgrade. pg_upgrade is not going to do that waiting.
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.
The existing pg_control clearly says that the cluster was shut down,
so it's not clear why there's still a postmaster.pid file there.
There's some debugging to be done yet about how that got to be that way.
(AFAICS the RPM upgrade process ought to shut down the old postmaster
before installing a new one; but somehow that went wrong, or else a
doppelganger postmaster.pid rose from the dead. Anyway, that's not a
matter for this list because it involves Red Hat upgrade processes, not
anything supplied by the community.)
In the meantime, I was wondering a bit why pg_upgrade looks at the
postmaster.pid file at all. Generally we recommend that startup scripts
*not* look at the lock file but just try to start a postmaster, and
leave it to the postmaster to decide if there's a valid lockfile
present. Is it really appropriate for pg_upgrade to do this
differently? I think the complained-of case would have gone through
cleanly if that error check weren't there, or in any case the postmaster
would have done a better job of checking for a conflicting postmaster.
regards, tom lane