Re: pg_upgrade's bindir options could be optional

Поиск
Список
Период
Сортировка
От Bruce Momjian
Тема Re: pg_upgrade's bindir options could be optional
Дата
Msg-id 201105080019.p480JSE11768@momjian.us
обсуждение исходный текст
Ответ на Re: pg_upgrade's bindir options could be optional  (Peter Eisentraut <peter_e@gmx.net>)
Список pgsql-hackers
Peter Eisentraut wrote:
> On fre, 2011-05-06 at 21:54 -0300, Alvaro Herrera wrote:
> > Excerpts from Tom Lane's message of vie may 06 17:11:35 -0300 2011:
> > 
> > > As an example, the proposed defaults would be not only wrong, but
> > > disastrous in the perfectly-reasonable situation where the user has
> > > moved the old installation aside and then installed the new
> > executables
> > > in the same place the old ones used to be.  My current RPM packaging
> > of
> > > pg_upgrade would be at risk for the same reason.
> > 
> > Eh, disastrous?  Don't we check the versions reported by each
> > postmaster before attempting to do anything?  Because if we do, the
> > worst that would happen is that the user gets a version mismatch
> > error.
> > And if we don't ... well, we should. 
> 
> Yeah, we'd obviously have to decorate that with some checks and error
> reporting.  But AFAICT we only use the old bindir for running
> pg_controldata, so what could go wrong(tm).

Uh, we use that bindir to run the right pg_ctl and psql and stuff. 
Everything run should be the matching directory, except for pg_dumpall
which uses the new one.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +


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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Fix for pg_upgrade user flag
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: pg_upgrade's bindir options could be optional