From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Ian Harding <harding(dot)ian(at)gmail(dot)com> |
Cc: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, General PostgreSQL List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade |
Date: | 2013-02-16 01:54:47 |
Message-ID: | 20130216015447.GE12029@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Feb 15, 2013 at 10:36:25AM -0800, Ian Harding wrote:
> Maybe this is it. 8.4 pg_ctl docs say it uses "psql -l" to see if it's
> finished when you use -w. It also says
>
> PGPORT
>
> Default port for psql (used by the -w option).
>
> And since pg_upgrade uses a funky port, it might miss unless the PGPORT
> environment variable is set to match.
>
> I'll try that tonight.
Yes, you are getting close to the answer. ;-) The problem is that
Postgres doesn'isn't checking the right port number or socket location
or something else. This was all improved in Postgres 9.1:
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.
I am guessing there is something non-standard about your old cluster,
and 8.4's pg_ctl -w can't handle it. Tell me what is non-standard and I
can help further. Another idea is to make the old cluster use defaults
for everything and do the upgrade.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
From | Date | Subject | |
---|---|---|---|
Next Message | David Kerr | 2013-02-16 06:21:14 | Re: PG9.2.3. Query hanging: SELECT count(*) FROM pg_catalog.pg_class... |
Previous Message | Satoshi Nagayasu | 2013-02-16 01:52:51 | Re: Visual query builder for PosgreSQL? |