The following bug has been logged on the website:

Bug reference: 6347
Logged by: Alexander Fortin
Email address: alexander.fortin (AT) gmail (DOT) com
PostgreSQL version: 9.1.2
Operating system: Ubuntu 10.04.3
Description:

Hi folks. I'm testing 9.1.2 (source compiled) pg_upgrade (upgrading from
8.4.9) and it seems that the problem exposed in bug #6085 is still there. In
my case, the only way to make pg_upgrade work is to actually force
unix_socket_directory = '/tmp/' for the 8.4.9 cluster.

Running in verbose mode
Performing Consistency Checks on Old Live Server
------------------------------------------------
Checking current, bin, and data directories ok
Checking cluster versions ok
connection to database failed: could not connect to server: No such file or
directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?


--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Mon, Dec 19, 2011 at 03:06:31PM +0000, alexander.fortin (AT) gmail (DOT) com wrote:
Yes. I wasn't clear in my email reply:

http://archives.postgresql.org/pgsql...7/msg00092.php

When I said this will be fixed in 9.1, I meant pg_ctl will work in 9.1
for non-default socket directories, but when the 9.1 pg_upgrade accesses
the 8.4 server, it has to use the 8.4 pg_ctl to do it, and that can't be
fixed in a back-branch.

I think we can only call this fixed when the old and new server is >= PG
9.1. Yeah, this isn't good, but it is the best we can do.

--
Bruce Momjian <bruce (AT) momjian (DOT) us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Fri, Feb 03, 2012 at 09:59:07AM -0500, Bruce Momjian wrote:
Actually, thinking more about this, the old pg_upgrade didn't use pg_ctl
wait/-w mode, but rather kept trying to connect until the server was up.
Once pg_ctl -w worked in more cases in PG 9.1, the new pg_upgrade
started using pg_ctl -w, but I didn't consider that we were unable to
fix pg_ctl -w for non-standard settings in back branches.

This can be seen as a regression in pg_upgrade functionality. Not sure
what we can do about this, but perhaps there should be a mention in the
pg_upgrad docs. I am going to wait to see if anyone else reports this
problem --- the last report was against Postgres 9.0 in July, 2011.

FYI, here is the 9.1 relesase not mention of the fix:

Improve <application>pg_ctl</> start's "wait"
(-w) option (Bruce Momjian, Tom Lane)

The wait mode is now significantly more robust. It will not get
confused by non-default postmaster port numbers, non-default
Unix-domain socket locations, permission problems, or stale
postmaster lock files.


--
Bruce Momjian <bruce (AT) momjian (DOT) us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

Excerpts from Bruce Momjian's message of vie feb 03 15:52:29 -0300 2012:

Hm, so what was wrong with just keep trying to connect? Surely it's not
optimal, but if it's more robust than the alternative, maybe it's
preferrable.

--=20
=C3=81lvaro Herrera <alvherre (AT) commandprompt (DOT) com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

--=20
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs

On Fri, Feb 03, 2012 at 04:17:50PM -0300, Alvaro Herrera wrote:
Well, it didn't always work. What we used to do, and still do, is to
pass the port number in via -o '-p 4444', but that didn't handle the
socket location, which is the case for the bug reporter.

Now that I think of it, we might not have a regression from 9.0 --- my
big point is that the socket location, while fixed in 9.1, didn't fix it
in back branches, and therefore pg_upgrade doesn't handle them for old
pre-9.1 clusters.

I was unclear why the original pg_upgrade code used a separate
connection loop instead of pg_ctl -w, but when I found how broken pg_ctl
-w was, I fixed pg_ctl so at least going forward, it works for all
use-cases.

--
Bruce Momjian <bruce (AT) momjian (DOT) us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

--
Sent via pgsql-bugs mailing list (pgsql-bugs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs