Re: [HACKERS] PG_UPGRADE status?

От: Tom Lane
Тема: Re: [HACKERS] PG_UPGRADE status?
Дата: ,
Msg-id: 8412.936896701@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen)
Список: pgsql-hackers

Скрыть дерево обсуждения

PG_UPGRADE status?  (Lamar Owen, )
 Re: [HACKERS] PG_UPGRADE status?  (Bruce Momjian, )
  Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen, )
   Re: [HACKERS] PG_UPGRADE status?  (Bruce Momjian, )
    Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen, )
     Re: [HACKERS] PG_UPGRADE status?  (Tom Lane, )
      Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen, )
       Re: [HACKERS] PG_UPGRADE status?  (Tom Lane, )
        Re: [HACKERS] PG_UPGRADE status  (Bruce Momjian, )
         Re: [HACKERS] PG_UPGRADE status  (Tom Lane, )
          Re: [HACKERS] PG_UPGRADE status  (Bruce Momjian, )
          Re: [HACKERS] PG_UPGRADE status  (Bruce Momjian, )
         Re: [HACKERS] PG_UPGRADE status  (Lamar Owen, )
          Re: [HACKERS] PG_UPGRADE status  (Bruce Momjian, )
           Re: [HACKERS] PG_UPGRADE status  (Tom Lane, )
        Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen, )
         Re: [HACKERS] PG_UPGRADE status?  (Bruce Momjian, )
         Re: [HACKERS] PG_UPGRADE status?  (Tom Lane, )
          RPM restrictions (was:Re: [HACKERS] PG_UPGRADE status?)  (Lamar Owen, )
     Re: [HACKERS] PG_UPGRADE status?  (Bruce Momjian, )
      Re: [HACKERS] PG_UPGRADE status?  (Lamar Owen, )
       Re: [HACKERS] PG_UPGRADE status?  (Bruce Momjian, )

Lamar Owen <> 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



В списке pgsql-hackers по дате сообщения:

От: Edwin Ramirez
Дата:
Сообщение: Re: [HACKERS] Postgres Performance
От: Thomas Lockhart
Дата:
Сообщение: Re: [COMMITTERS] pgsql/src/backend/lib (stringinfo.c)