9.3beta2: Failure to pg_upgrade - Mailing list pgsql-bugs

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