On Mon, Feb 17, 2014 at 12:54:02PM -0500, Bruce Momjian wrote:
> > > Does that help? Did you use a different environment for the check and
> > > non-check phases?
> >
> > I found a fiable solution: remove the -w option on the pg_ctl' wrapper
> > (and added sleep 5 for waiting the launch) when pg_upgrade want to
> > start PG. Tested on several db w/o issues. This option is broken on PG
> > <9 (several workaround exist in the code of pg_upgrade for it).
>
> Oh, that's interesting. We used to have a loop in there for cases where
> you we couldn't use -w, like for non-default connection settings, but I
> thought -w still worked for defaults, even back to 8.4.
>
> It is possible we removed something that we should no one needed anymore
> but that 8.4 needs, but I am unclear what that would be.
I checked this and we use the pg_ctl version that matches the server we
are starting/stopping, so that kills the idea we removed something in
pg_ctl needed in older versions:
snprintf(cmd, sizeof(cmd),
"\"%s/pg_ctl\" -w -l \"%s\" -D \"%s\" -o \"-p %d%s%s %s%s\" start",
cluster->bindir, SERVER_LOG_FILE, cluster->pgconfig, cluster->port,
---------------
You saw the failure running pg_dumpall --globals on the old server.
Does pg_ctl -w work on the old/8.4 server, meaning can you run the
pg_ctl -w command that appears in the pg_upgrade logs, and then run a
pg_dumpall command right after?
--
Bruce Momjian <bruce@xxxxxxxxxx> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
