Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)
Дата
Msg-id Pine.LNX.4.21.0010302151540.777-100000@peter.localdomain
обсуждение исходный текст
Ответ на Re: Re: [GENERAL] 7.0 vs. 7.1 (was: latest version?)  (Lamar Owen <lamar.owen@wgcr.org>)
Список pgsql-hackers
Lamar Owen writes:

> In the environment of the general purpose OS upgrade, the RPM's
> installation scripts cannot fire up a backend, nor can it assume one
> is running or is not running, nor can the RPM installation scripts
> fathom from the run-time environment whether they are being run from a
> command line or from the OS upgrade (except on Linux Mandrake, which
> allows such usage).

I don't understand why this is so.  It seems perfectly possible that some
%preremovebeforeupdate starts a postmaster, runs pg_dumpall, saves the
file somewhere, then the %postinstallafterupdate runs the inverse
operation.  Disk space is not a valid objection, you'll never get away
without 2x storage.  Security is not a problem either.  Are you not
upgrading in proper dependency order or what?  Everybody does dump,
remove, install, undump; so can the RPMs.

Okay, so it's not as great as a new KDE starting up and asking "may I
update your configuration files?", but understand that the storage format
is optimized for performance, not easy processing by external tools or
something like that.

-- 
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Zeugswetter Andreas SB
Дата:
Сообщение: AW: regression failure/UnixWare7.1.1/current sources
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: LIMIT in DECLARE CURSOR: request for comments