Skip site navigation (1) Skip section navigation (2)

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

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Olivier LEVESQUE <olevesque3(at)gmail(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6085: pg_upgrade fails when unix_socket_directory != /tmp
Date: 2011-07-12 00:41:47
Message-ID: 201107120041.p6C0flv29756@momjian.us (view raw or flat)
Thread:
Lists: pgsql-bugs
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(at)gmail(dot)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(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs

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

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

In response to

Responses

pgsql-bugs by date

Next:From: Jeff DavisDate: 2011-07-12 00:48:06
Subject: Window function bug
Previous:From: Bruce MomjianDate: 2011-07-12 00:35:37
Subject: Re: BUG #6082: server segfault - pg_stat_reset_shared(null)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group