Обсуждение: Can't upgrade a DB from 8.4 to 9.3 with pg_uprade: pg 9 not started
Hi,
I'm trying to upgrade a 8.4 DB (from Debian packages on Debian Lenny)
to 9.3 (installation from source) with pg_upgrade. But he doesn't
launch the new postmaster. Any ideas?
postgres@SPV:~$ /opt/nova/current/nova/parts/pg93/bin/pg_upgrade -b
/usr/lib/postgresql/8.4/bin -B /opt/nova/current/nova/parts/pg93/bin/
-d /srv/postgresql/8.4/main/ -D /srv/postgresql/9.3/main --check
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for large objects ok
Checking for presence of required libraries ok
Checking database user is a superuser ok
Checking for prepared transactions ok
*Clusters are compatible*
postgres@SPV:/tmp$ /opt/nova/current/nova/parts/pg93/bin/pg_upgrade -b
/usr/lib/postgresql/8.4/bin -B /opt/nova/current/nova/parts/pg93/bin
-d /srv/postgresql/8.4/main/ -D /srv/postgresql/9.3/main
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for large objects ok
Creating dump of global objects
*failure*
Consult the last few lines of "pg_upgrade_utility.log" for
the probable cause of the failure.
Failure, exiting
postgres@SPV:/tmp$ ls
pg_upgrade_internal.log pg_upgrade_server.log
pg_upgrade_utility.log upgrade_successful
postgres@SPV:/tmp$ cat pg_upgrade_internal.log
-----------------------------------------------------------------
pg_upgrade run on Thu Feb 13 23:13:54 2014
-----------------------------------------------------------------
Performing Consistency Checks
-----------------------------
Checking cluster versions ok
Checking database user is a superuser ok
Checking for prepared transactions ok
Checking for reg* system OID user data types ok
Checking for contrib/isn with bigint-passing mismatch ok
Checking for large objects ok
Creating dump of global objects
*failure*
Consult the last few lines of "pg_upgrade_utility.log" for
the probable cause of the failure.
postgres@SPV:/tmp$ cat pg_upgrade_server.log
-----------------------------------------------------------------
pg_upgrade run on Thu Feb 13 23:13:54 2014
-----------------------------------------------------------------
command: "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -l
"pg_upgrade_server.log" -D "/srv/postgresql/8.4/main/" -o "-p 50432 -c
autovacuum=off -c autovacuum_freeze_max_age=2000000000 -c
listen_addresses='' -c unix_socket_permissions=0700" start >>
"pg_upgrade_server.log" 2>&1
waiting for server to start.... done
server started
command: "/usr/lib/postgresql/8.4/bin/pg_ctl" -w -D
"/srv/postgresql/8.4/main/" -o "" -m fast stop >>
"pg_upgrade_server.log" 2>&1
waiting for server to shut down.... done
server stopped
postgres@SPV:/tmp$ cat pg_upgrade_utility.log
-----------------------------------------------------------------
pg_upgrade run on Thu Feb 13 23:13:54 2014
-----------------------------------------------------------------
command: "/opt/nova/current/nova/parts/pg93/bin/pg_dumpall" --port
50432 --username "postgres" --schema-only --globals-only
--quote-all-identifiers --binary-upgrade -f
pg_upgrade_dump_globals.sql >> "pg_upgrade_utility.log" 2>&1
pg_dumpall: could not connect to database "template1": 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.50432"?
--
Sebastien Douche <sdouche@gmail.com>
Twitter: @sdouche / G+: +sdouche
On Thu, Feb 13, 2014 at 11:24 PM, Sebastien Douche <sdouche@gmail.com> wrote: > Any ideas? Forgot to say I can launch manually the new postmaster: postgres@SPV:/tmp$ /opt/nova/current/nova/parts/pg93/bin/pg_ctl -w -D /srv/postgresql/9.3/main/ -o "-p 50432 -c autovacuum=off -c autovacuum_freeze_max_age=2000000000 -c listen_addresses='' -c unix_socket_permissions=0700" start waiting for server to start....LOG: database system was shut down at 2014-02-13 20:16:14 CET LOG: database system is ready to accept connections done server started -- Sebastien Douche <sdouche@gmail.com> Twitter: @sdouche / G+: +sdouche
On Thu, Feb 13, 2014 at 11:24:03PM +0100, Sebastien Douche wrote: > Hi, > I'm trying to upgrade a 8.4 DB (from Debian packages on Debian Lenny) > to 9.3 (installation from source) with pg_upgrade. But he doesn't > launch the new postmaster. Any ideas? > > postgres@SPV:~$ /opt/nova/current/nova/parts/pg93/bin/pg_upgrade -b > /usr/lib/postgresql/8.4/bin -B /opt/nova/current/nova/parts/pg93/bin/ > -d /srv/postgresql/8.4/main/ -D /srv/postgresql/9.3/main --check > Performing Consistency Checks > ----------------------------- > Checking cluster versions ok > Checking database user is a superuser ok > Checking for prepared transactions ok > Checking for reg* system OID user data types ok > Checking for contrib/isn with bigint-passing mismatch ok > Checking for large objects ok > Checking for presence of required libraries ok > Checking database user is a superuser ok > Checking for prepared transactions ok > > *Clusters are compatible* Uh, this connects to both old and new servers, so I am confused why it later fails. > postgres@SPV:/tmp$ cat pg_upgrade_utility.log > > ----------------------------------------------------------------- > pg_upgrade run on Thu Feb 13 23:13:54 2014 > ----------------------------------------------------------------- > > command: "/opt/nova/current/nova/parts/pg93/bin/pg_dumpall" --port > 50432 --username "postgres" --schema-only --globals-only > --quote-all-identifiers --binary-upgrade -f > pg_upgrade_dump_globals.sql >> "pg_upgrade_utility.log" 2>&1 > pg_dumpall: could not connect to database "template1": 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.50432"? This is using /tmp because the old server is pre-9.1; it would normally use the current directory for the socket file. Are you perhaps using a non-standard setting? Our docs say: If using a pre-9.1 old server that is using a non-default Unix-domain socket directory or a default that differs from the default of the new cluster, set <envar>PGHOST</> to point to the old server's socket location. (This is not relevant on Windows.) Does that help? Did you use a different environment for the check and non-check phases? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
On Fri, Feb 14, 2014 at 3:15 AM, Bruce Momjian <bruce@momjian.us> wrote:\ Hi Bruce, thanks for your time. > This is using /tmp because the old server is pre-9.1; it would normally > use the current directory for the socket file. Are you perhaps using a > non-standard setting? Our docs say: > > If using a pre-9.1 old server that is using a non-default Unix-domain > socket directory or a default that differs from the default of the > new cluster, set <envar>PGHOST</> to point to the old server's socket > location. (This is not relevant on Windows.) Right, but It's broken also if I set unix_socket_directory to /tmp. > 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). -- Sebastien Douche <sdouche@gmail.com> Twitter: @sdouche / G+: +sdouche
On Fri, Feb 14, 2014 at 06:16:02PM +0100, Sebastien Douche wrote: > On Fri, Feb 14, 2014 at 3:15 AM, Bruce Momjian <bruce@momjian.us> wrote:\ > > Hi Bruce, > thanks for your time. > > > This is using /tmp because the old server is pre-9.1; it would normally > > use the current directory for the socket file. Are you perhaps using a > > non-standard setting? Our docs say: > > > > If using a pre-9.1 old server that is using a non-default Unix-domain > > socket directory or a default that differs from the default of the > > new cluster, set <envar>PGHOST</> to point to the old server's socket > > location. (This is not relevant on Windows.) > > Right, but It's broken also if I set unix_socket_directory to /tmp. Oh. > > 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. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + Everyone has their own god. +
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@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +