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

Started by Olivier LEVESQUEalmost 15 years ago3 messagesbugs
Jump to latest
#1Olivier LEVESQUE
olevesque3@gmail.com

The following bug has been logged online:

Bug reference: 6085
Logged by: Olivier LEVESQUE
Email address: olevesque3@gmail.com
PostgreSQL version: 9.0.3
Operating system: RHEL 5.4 Linux 2.6.18 x86_64
Description: pg_upgrade fails when unix_socket_directory != /tmp
Details:

Running pg_upgrade on clusters with unix_socket_directory parameter
different (e.g. /pgqdata/pgserver01/data) than default value (/tmp) fails:

$ 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 --check
Performing Consistency Checks
-----------------------------
Checking old data directory (/pgqdata/pgserver01/data) ok
Checking old bin directory (/opt/pgsql/na/8.4.4/bin) ok
Checking new data directory (/pgqdata/pgserver02/data) ok
Checking new bin directory (/opt/pgsql/na/9.0.3/bin) ok
Trying to start old server
.................ok

Unable 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=off -c
autovacuum_freeze_max_age=2000000000" start >> "/dev/null" 2>&1
Perhaps pg_hba.conf was not set to "trust".

===> Here, the error message given is not true, because old postmaster 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) ok
Checking old bin directory (/opt/pgsql/na/8.4.4/bin) ok
Checking new data directory (/pgqdata/pgserver02/data) ok
Checking new bin directory (/opt/pgsql/na/9.0.3/bin) 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"?

===> Why searching socket in /tmp while it is not the directory in
postgresql.conf?

Changing (commenting #unix_socket_directory in postgresql.conf) solves the
problem and pg_upgrade runs fine.

#2Bruce Momjian
bruce@momjian.us
In reply to: Olivier LEVESQUE (#1)
Re: BUG #6085: pg_upgrade fails when unix_socket_directory != /tmp

This is caused by pg_ctl not properly understanding non-default socket
directories --- this is fixed in Postgres 9.1. Not 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: 6085
Logged by: Olivier LEVESQUE
Email address: olevesque3@gmail.com
PostgreSQL version: 9.0.3
Operating system: RHEL 5.4 Linux 2.6.18 x86_64
Description: pg_upgrade fails when unix_socket_directory != /tmp
Details:

Running pg_upgrade on clusters with unix_socket_directory parameter
different (e.g. /pgqdata/pgserver01/data) than default value (/tmp) fails:

$ 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 --check
Performing Consistency Checks
-----------------------------
Checking old data directory (/pgqdata/pgserver01/data) ok
Checking old bin directory (/opt/pgsql/na/8.4.4/bin) ok
Checking new data directory (/pgqdata/pgserver02/data) ok
Checking new bin directory (/opt/pgsql/na/9.0.3/bin) ok
Trying to start old server
.................ok

Unable 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=off -c
autovacuum_freeze_max_age=2000000000" start >> "/dev/null" 2>&1
Perhaps pg_hba.conf was not set to "trust".

===> Here, the error message given is not true, because old postmaster 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) ok
Checking old bin directory (/opt/pgsql/na/8.4.4/bin) ok
Checking new data directory (/pgqdata/pgserver02/data) ok
Checking new bin directory (/opt/pgsql/na/9.0.3/bin) 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"?

===> Why searching socket in /tmp while it is not the directory in
postgresql.conf?

Changing (commenting #unix_socket_directory in postgresql.conf) solves the
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

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

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

#3Olivier LEVESQUE
olevesque3@gmail.com
In reply to: Bruce Momjian (#2)
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>:

Show quoted text

This is caused by pg_ctl not properly understanding non-default socket
directories --- this is fixed in Postgres 9.1.  Not 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:      6085
Logged by:          Olivier LEVESQUE
Email address:      olevesque3@gmail.com
PostgreSQL version: 9.0.3
Operating system:   RHEL 5.4 Linux 2.6.18 x86_64
Description:        pg_upgrade fails when unix_socket_directory != /tmp
Details:

Running pg_upgrade on clusters with unix_socket_directory parameter
different (e.g. /pgqdata/pgserver01/data) than default value (/tmp) fails:

$ 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 --check
Performing Consistency Checks
-----------------------------
Checking old data directory (/pgqdata/pgserver01/data)      ok
Checking old bin directory (/opt/pgsql/na/8.4.4/bin)        ok
Checking new data directory (/pgqdata/pgserver02/data)      ok
Checking new bin directory (/opt/pgsql/na/9.0.3/bin)        ok
Trying to start old server
.................ok

 Unable 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=off -c
autovacuum_freeze_max_age=2000000000" start >> "/dev/null" 2>&1
Perhaps pg_hba.conf was not set to "trust".

===> Here, the error message given is not true, because old postmaster 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)      ok
Checking old bin directory (/opt/pgsql/na/8.4.4/bin)        ok
Checking new data directory (/pgqdata/pgserver02/data)      ok
Checking new bin directory (/opt/pgsql/na/9.0.3/bin)        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"?

===> Why searching socket in /tmp while it is not the directory in
postgresql.conf?

Changing (commenting #unix_socket_directory in postgresql.conf) solves the
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

--
 Bruce Momjian  <bruce@momjian.us>        http://momjian.us
 EnterpriseDB                             http://enterprisedb.com

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