Thread: pg_upgrade's bindir options could be optional
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?
Peter Eisentraut <peter_e@gmx.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
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. -- Álvaro Herrera <alvherre@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support
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. I don't think the server would start because the postmaster binary would not match the PG_VERSION file version. For people who have PG-version-specific directories, the postmaster.opts would work fine, but for people who are moving those directories, odds are they never start them after moving them, so the postmaster.opts would be wrong. I think it just might be too confusing to say that the binary directory specification is only needed if you didn't move data directories around after stopping them for the last time. Another interesting approach would be to assume the /bin directory is ../bin from the data directory. That would work for some installs, particularly for people moving things around, but again, it is worth trying to default something that isn't going to be 100% right? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
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).
On lör, 2011-05-07 at 13:33 -0400, Bruce Momjian wrote: > Another > interesting approach would be to assume the /bin directory is ../bin > from the data directory. That would work for some installs, > particularly for people moving things around, but again, it is worth > trying to default something that isn't going to be 100% right? In practice, there are the two main camps of parallel installation and move old installation out of the way. They are probably both pretty big (Debias camp 1, Red Hat is camp 2, for a start). So it would be worth doing something to help one camp or the other. On that other hand, we don't have any data on how many people have the bindir at ../bin from the data directory, or whether it would be the old or the new bindir.
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. +
Peter Eisentraut wrote: > On l?r, 2011-05-07 at 13:33 -0400, Bruce Momjian wrote: > > Another > > interesting approach would be to assume the /bin directory is ../bin > > from the data directory. That would work for some installs, > > particularly for people moving things around, but again, it is worth > > trying to default something that isn't going to be 100% right? > > In practice, there are the two main camps of parallel installation and > move old installation out of the way. They are probably both pretty big > (Debias camp 1, Red Hat is camp 2, for a start). So it would be worth > doing something to help one camp or the other. > > On that other hand, we don't have any data on how many people have the > bindir at ../bin from the data directory, or whether it would be the old > or the new bindir. Yes, it was too complex which is why I made it explicit. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Peter Eisentraut <peter_e@gmx.net> writes:
> On lör, 2011-05-07 at 13:33 -0400, Bruce Momjian wrote:
>> Another
>> interesting approach would be to assume the /bin directory is ../bin
>> from the data directory. That would work for some installs,
>> particularly for people moving things around, but again, it is worth
>> trying to default something that isn't going to be 100% right?
> In practice, there are the two main camps of parallel installation and
> move old installation out of the way. They are probably both pretty big
> (Debias camp 1, Red Hat is camp 2, for a start). So it would be worth
> doing something to help one camp or the other.
It's probably fair to ask whether setting up defaults for this would
actually help either "camp". In the case of the Red Hat RPMs,
pg_upgrade is invoked via a script which is perfectly content to specify
both bindirs explicitly. I doubt I'd remove those options even if I
thought the defaults would be right, because there's just no upside to
doing so. I would imagine the same is true for Debian --- surely this
is pretty mechanized? So the only cases where providing a default is
even theoretically useful are those where someone is invoking pg_upgrade
manually. I suggest that if that's going on, the situation is probably
nonstandard enough that we should have considerable doubt about whether
a default is likely to be correct.
Again, I don't have any particular fear about defaulting --new-bindir.
I *do* have a lot of concern about defaulting --old-bindir.
regards, tom lane