9.3beta2: Failure to pg_upgrade

From: Jesse Denardo <denaje(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: 9.3beta2: Failure to pg_upgrade
Date: 2013-07-30 14:17:52
Message-ID: CANiVXAj4c88YqipsyFQPboqMudnjcNTdB3pqe8ReXqAFQ=HXyA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Name: Jesse Denardo
Release: 9.2.2 -> 9.3beta2
Test Type: Install/Upgrade Test
Test Detail: pg_upgrade in a fresh install of 9.3beta2
Platform: Debian Linux 6.0.5
Installation Method: From source
Platform Detail: Debian Linux 6.0.5, 2.6.32.45-grsec-2.2.2-r3, x86_64
Test Procedure:

I made a byte for byte copy of our exsting 9.2.2 Postgres directory (which
includes the data directory), changed the port, and started it up. I
pointed our dev application at the new port, and everything worked as
expected. I then followed the procedure outlined here:
http://www.postgresql.org/docs/9.3/static/pgupgrade.html

I installed 9.3beta2 into a new directory from source, installed Postgis
2.1 and our required contrib modules, ran initdb, and ran pg_upgrade
pointing at the right spots. The exact commands I used were:

$ whoami
postgres

$ pwd
/home/postgres

$ 9.3beta2/bin/initdb 9.3beta2/data
The files belonging to this database system will be owned by user
"postgres".
This user must also own the server process.

The database cluster will be initialized with locales
COLLATE: C
CTYPE: en_US.UTF-8
MESSAGES: en_US.UTF-8
MONETARY: en_US.UTF-8
NUMERIC: en_US.UTF-8
TIME: en_US.UTF-8
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".

Data page checksums are disabled.

creating directory 9.3beta2/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
creating configuration files ... ok
creating template1 database in 9.3beta2/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating collations ... ok
creating conversions ... ok
creating dictionaries ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
loading PL/pgSQL server-side language ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok
syncing data to disk ... ok

WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.

Success. You can now start the database server using:

9.3beta2/bin/postgres -D 9.3beta2/data
or
9.3beta2/bin/pg_ctl -D 9.3beta2/data -l logfile start

(At this point, starting the new database succeeds.)

$ 9.3beta2/bin/pg_upgrade --old-bindir=/home/postgres/9.2_dev/bin
--new-bindir=/home/postgres/9.3beta2/bin
--old-datadir=/home/postgres/9.2_dev/data
--new-datadir=/home/postgres/9.3beta2/data -u postgres

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
Creating dump of global objects ok
Creating dump of database schemas
ok
Checking for presence of required libraries ok
Checking database user is a superuser ok
Checking for prepared transactions ok

If pg_upgrade fails after this point, you must re-initdb the
new cluster before continuing.

Performing Upgrade
------------------
Analyzing all rows in the new cluster ok
Freezing all rows on the new cluster ok
Deleting files from new pg_clog ok
Copying old pg_clog to new server ok
Setting next transaction ID for new cluster ok
Setting oldest multixact ID on new cluster ok
Resetting WAL archives ok

*failure*
Consult the last few lines of "pg_upgrade_server.log" for
the probable cause of the failure.

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 "/home/postgres/.s.PGSQL.50432"?

could not connect to new postmaster started with the command:
"/home/postgres/9.3beta2/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D
"/home/postgres/9.3beta2/data" -o "-p 50432 -b -c synchronous_commit=off -c
fsync=off -c full_page_writes=off -c listen_addresses='' -c
unix_socket_permissions=0700 -c unix_socket_directories='/home/postgres'"
start
Failure, exiting

Failure: Error, possible compatibility issue
Results: See above. The pg_upgrade_server.log contains at the end:

command: "/home/postgres/9.3beta2/bin/pg_ctl" -w -l "pg_upgrade_server.log"
-D "/home/postgres/9.3beta2/data" -o "-p 50432 -b -c synchronous_commit=off
-c fsync=off -c full_page_writes=off -c listen_addresses='' -c
unix_socket_permissions=0700 -c unix_socket_directories='/home/postgres'"
start >> "pg_upgrade_server.log" 2>&1
waiting for server to start....LOG: database system was shut down at
2013-07-30 09:57:58 EDT
FATAL: could not access status of transaction 2983
DETAIL: Could not read from file "pg_multixact/offsets/0000" at offset
8192: Success.
LOG: startup process (PID 5239) exited with exit code 1
LOG: aborting startup due to startup process failure
.... stopped waiting
pg_ctl: could not start server
Examine the log output.

At this point, attempting to start the server fails with the same error
until I delete the data directory and re-initdb.

--
Jesse Denardo

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message bricklen 2013-07-30 15:13:20 Re: Fwd: corrupted files
Previous Message Gustavo Bacchin 2013-07-30 13:52:07 Ferramenta de Modelagem

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2013-07-30 16:55:28 Re: ALTER SYSTEM SET command to change postgresql.conf parameters (RE: Proposal for Allow postgresql.conf values to be changed via SQL [review])
Previous Message Pavel Stehule 2013-07-30 13:58:57 Re: ToDo: possible more rights to database owners