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