Re: pg_upgrade's bindir options could be optional

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade's bindir options could be optional
Date: 2011-05-06 20:11:35
Message-ID: 2250.1304712695@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
> Just a thought: To make things a bit easier, the bindir options of
> pg_upgrade (-b/-B, --old-bindir/--new-bindir) could be made optional, I
> think. The new bindir should normally be the one that pg_upgrade itself
> is in. And the old bindir could be found out by looking at the
> postmaster.opts file in the old data directory. At least by default,
> this would make the pg_upgrade invocation a lot more compact; it would
> just be: pg_upgrade -d oldir -D newdir.

> Comments?

I don't think we should rely on postmaster.opts being there, let alone
being trustworthy. It's probably not unreasonable to let --new-bindir
default to the directory pg_upgrade is in, but I'm much less comfortable
with allowing --old-bindir to be defaulted.

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2011-05-06 20:18:55 Re: VARIANT / ANYTYPE datatype
Previous Message Alvaro Herrera 2011-05-06 20:08:38 Re: VARIANT / ANYTYPE datatype