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

Re: BUG #6347: Reopening bug #6085

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: alexander(dot)fortin(at)gmail(dot)com
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #6347: Reopening bug #6085
Date: 2012-02-03 18:52:29
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
On Fri, Feb 03, 2012 at 09:59:07AM -0500, Bruce Momjian wrote:
> On Mon, Dec 19, 2011 at 03:06:31PM +0000, alexander(dot)fortin(at)gmail(dot)com wrote:
> > The following bug has been logged on the website:
> > 
> > Bug reference:      6347
> > Logged by:          Alexander Fortin
> > Email address:      alexander(dot)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"?
> Yes.  I wasn't clear in my email reply:
> 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.

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>

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

In response to


pgsql-bugs by date

Next:From: Alvaro HerreraDate: 2012-02-03 19:17:50
Subject: Re: BUG #6347: Reopening bug #6085
Previous:From: Dharmendra GoyalDate: 2012-02-03 17:31:38
Subject: Re: BUG #6404: postgres account not created during unattended install

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