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 по дате отправления: