Обсуждение: BUG #6085: pg_upgrade fails when unix_socket_directory != /tmp
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.
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. +
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. + >