Re: BUG #6085: pg_upgrade fails when unix_socket_directory != /tmp

Fine. Glad to know it is fixed in 9.1.
As far as the workaround is simple, it is a minor issue.

Thank you very much.

2011/7/12 Bruce Momjian <bruce@momjian.us>:
>
> This is caused by pg_ctl not properly understanding non-default socket
> directories --- this is fixed in Postgres 9.1. =A0Not much pg_ctl can do
> to fix that except ignore a pg_ctl error return code, which isn't good.
> It will be fine in 9.1.
>
> -------------------------------------------------------------------------=
--
>
> Olivier LEVESQUE wrote:
>>
>> The following bug has been logged online:
>>
>> Bug reference: =A0 =A0 =A06085
>> Logged by: =A0 =A0 =A0 =A0 =A0Olivier LEVESQUE
>> Email address: =A0 =A0 =A0olevesque3@gmail.com
>> PostgreSQL version: 9.0.3
>> Operating system: =A0 RHEL 5.4 Linux 2.6.18 x86_64
>> Description: =A0 =A0 =A0 =A0pg_upgrade fails when unix_socket_directory =
!=3D /tmp
>> Details:
>>
>> Running pg_upgrade on clusters with unix_socket_directory parameter
>> different (e.g. /pgqdata/pgserver01/data) than default value (/tmp) fail=
s:
>>
>> $ pg_upgrade -d /pgqdata/pgserver01/data -D /pgqdata/pgserver02/data -b
>> /opt/pgsql/na/8.4.4/bin -B /opt/pgsql/na/9.0.3/bin -p 5432 -P 5433 --che=
ck
>> Performing Consistency Checks
>> -----------------------------
>> Checking old data directory (/pgqdata/pgserver01/data) =A0 =A0 =A0ok
>> Checking old bin directory (/opt/pgsql/na/8.4.4/bin) =A0 =A0 =A0 =A0ok
>> Checking new data directory (/pgqdata/pgserver02/data) =A0 =A0 =A0ok
>> Checking new bin directory (/opt/pgsql/na/9.0.3/bin) =A0 =A0 =A0 =A0ok
>> Trying to start old server
>> .................ok
>>
>> =A0Unable to start old postmaster with the command:
>> "/opt/pgsql/na/8.4.4/bin/pg_ctl" -l "/dev/null" -D
>> "/pgqdata/pgserver01/data" -o " -p 5432 -c autovacuum=3Doff -c
>> autovacuum_freeze_max_age=3D2000000000" start >> "/dev/null" 2>&1
>> Perhaps pg_hba.conf was not set to "trust".
>>
>>
>> =3D=3D=3D> Here, the error message given is not true, because old postma=
ster has
>> been started succesfuly. It is just the connection test that failed.
>>
>> A subsequent start (with old cluster running) of --check gives a better
>> information:
>>
>> PerForming Consistency Checks on Old Live Server
>> ------------------------------------------------
>> Checking old data directory (/pgqdata/pgserver01/data) =A0 =A0 =A0ok
>> Checking old bin directory (/opt/pgsql/na/8.4.4/bin) =A0 =A0 =A0 =A0ok
>> Checking new data directory (/pgqdata/pgserver02/data) =A0 =A0 =A0ok
>> Checking new bin directory (/opt/pgsql/na/9.0.3/bin) =A0 =A0 =A0 =A0ok
>> Connection to database failed: could not connect to server: No such file=
 or
>> directory
>> =A0 =A0 =A0 =A0 Is the server running locally and accepting
>> =A0 =A0 =A0 =A0 connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
>>
>> =3D=3D=3D> Why searching socket in /tmp while it is not the directory in
>> postgresql.conf?
>>
>>
>> Changing (commenting #unix_socket_directory in postgresql.conf) solves t=
he
>> problem and pg_upgrade runs fine.
>>
>> --
>> Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-bugs
>
> --
> =A0Bruce Momjian =A0<bruce@momjian.us> =A0 =A0 =A0 =A0http://momjian.us
> =A0EnterpriseDB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 h=
ttp://enterprisedb.com
>
> =A0+ It's impossible for everything to be true. +
>