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

From Bruce Momjian
Subject Re: Yet another failure mode in pg_upgrade
Date
Msg-id 20120903152140.GF24132@momjian.us
Whole thread Raw
In response to Re: Yet another failure mode in pg_upgrade  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Sep  3, 2012 at 10:42:38AM -0400, Tom Lane wrote:
> 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.

Yes, agreed.  With your change, the new server doesn't have to match the
old server's sockdir anymore;  it is always going to use the current
directory.

So the text should be:
If running check on an old pre-9.1 Unix-like running server, andthe old running server is using a Unix-domain socket
directorydifferentfrom the default on the new server, set <envar>PGHOST</>to point to the socket location of the old
server.

--  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: Tom Lane
Date:
Subject: Re: Yet another failure mode in pg_upgrade
Next
From: Tom Lane
Date:
Subject: Re: Is this non-volatile pointer access OK?