Re: [HACKERS] PG_UPGRADE status?

Lamar Owen <lamar.owen@wgcr.org> writes:
> 2.)    The first rpm's preinstall script starts running.  The old version
> of that rpm is still installed at this point, BUT I CAN'T EXECUTE ANY
> DAEMONS -- the upgrade MIGHT be running in the wicked chroot environment
> of the RedHat installer, with its restrictive set of commands.  So, I
> CANNOT start a postmaster, nor can I be assured that a postmaster is
> running -- according to RedHat, since it could be running in the chroot
> installer, I can't even run a ps to SEE if postmaster is running
> (problems with a chrooted /proc...).  Therefore, the preinstall script
> CANNOT execute pg_dumpall.

chroot?  Where are you chrooted to?  It would seem from your description
that neither the preinstall nor postinstall scripts can even see the
/usr/local/pgsql directory tree, which would make it impossible to do
anything --- and would be an incredibly stupid way to design an
installer system, so I have to assume I'm misreading what you wrote.

Also, if the pre/postinstall scripts cannot contact existing processes,
then there is no hope of killing/restarting any kind of daemon process,
not just Postgres in particular.  The restrictions you claim are there
would make RPMs unusable for upgrading *anything* that has a
continuously running server process.  Is Red Hat really that far out
in left field?

> I can't even run a standalone backend --
> postmaster MIGHT be running.... And, I can't test to see if I'm running
> in the installer or not... ;-( The only thing I CAN do is check /tmp for
> the lock file.

chroot would generally imply that you can't see the regular /tmp dir,
either.
        regards, tom lane