Re: Yet another failure mode in pg_upgrade - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Yet another failure mode in pg_upgrade
Date
Msg-id 25927.1346683358@sss.pgh.pa.us
Whole thread Raw
In response to Re: Yet another failure mode in pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Yet another failure mode in pg_upgrade  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Bruce Momjian <bruce@momjian.us> writes:
> On Mon, Sep  3, 2012 at 10:07:43AM -0400, Tom Lane wrote:
>> It's not necessary, no?  The code now gets socket directory right
>> without help.

> Well, the doc comment is:

> +    If running check on an old pre-9.1 Unix-like running server, and the
> +    old and new servers use different Unix-domain socket directories,
> +    use the <option>-O</> option so the new server uses the same socket
> +    directory as the old server, and set <envar>PGHOST</> similarly.

> Remember, we can't get the socket directory for pre-9.1 servers.

Yeah, but even if you assume that pg_upgrade needs help for that, this
doc is wrong and overcomplicated.  The case that would be problematic
is where the old server is running with a unix_socket_directory that
is not the same as the default built into pg_upgrade's libpq.  It is
not necessary (given my patch) that the new server match that socket
directory.  What is necessary is that pg_upgrade be able to contact
the old server.  I think, but haven't tested, that it's sufficient
to set PGHOST to make that work.  The patched code will override
PGHOST for the new cluster anyway, since it will always specify
--host as the new-cluster socket directory.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Yet another failure mode in pg_upgrade
Next
From: Bruce Momjian
Date:
Subject: Re: Yet another failure mode in pg_upgrade