Re: pg_upgrade's bindir options could be optional - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: pg_upgrade's bindir options could be optional
Date
Msg-id 201105080019.p480JSE11768@momjian.us
Whole thread Raw
In response to Re: pg_upgrade's bindir options could be optional  (Peter Eisentraut <peter_e@gmx.net>)
List 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 by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fix for pg_upgrade user flag
Next
From: Bruce Momjian
Date:
Subject: Re: pg_upgrade's bindir options could be optional