Re: pg_upgrade's bindir options could be optional

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_upgrade's bindir options could be optional
Date: 2011-05-07 17:33:15
Message-ID: 201105071733.p47HXF013512@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2011-05-07 17:43:21 Re: Fix for pg_upgrade user flag
Previous Message Tom Lane 2011-05-07 17:07:55 Re: Process wakeups when idle and power consumption