Re: [BUGS] 9.3beta2: Failure to pg_upgrade
Alvaro, I applied the patch and tried upgrading again, and everything seemed to work as expected. We are now up and running the beta! -- Jesse Denardo On Fri, Aug 2, 2013 at 10:25 PM, Alvaro Herrera wrote: > Andres Freund escribió: > > On 2013-08-02 18:17:43 -0400, Alvaro Herrera wrote: > > > Alvaro Herrera escribió: > > > > > > > As it turns out, I have a patched slru.c that adds a new function to > > > > verify whether a page exists on disk. I created this for the commit > > > > timestamp module, for the BDR branch, but I think it's what we need > > > > here. > > > > > > Here's a patch that should fix the problem. Jesse, if you're able to > > > test it, please give it a run and let me know if it works for you. I > > > was able to upgrade an installation containing a problem that should > > > reproduce yours. > > > > Wouldn't it be easier to make pg_upgrade fudge pg_control to have a safe > > NextMultiXactId/Offset using pg_resetxlog? > > I don't understand. pg_upgrade already fudges pg_control to have a safe > next multi, namely the same value used by the old cluster. The reason > to preserve this value is that we must ensure no older value is > consulted in pg_multixact: those might be present in tuples that were > locked in the old cluster. (To be precise, this is the value to set as > oldest multi, not next multi. But of course, the next multi must be > greater than that one.) > > -- > Álvaro Herrerahttp://www.2ndQuadrant.com/ > PostgreSQL Development, 24x7 Support, Training & Services >
Re: [BUGS] 9.3beta2: Failure to pg_upgrade
$ 9.2_dev/bin/pg_controldata data pg_control version number:922 Catalog version number: 201204301 Database system identifier: 5789770930315980286 Database cluster state: shut down pg_control last modified: Tue 30 Jul 2013 09:57:54 AM EDT Latest checkpoint location: 6C/F8EE7500 Prior checkpoint location:6C/F8E90C18 Latest checkpoint's REDO location:6C/F8EE7500 Latest checkpoint's TimeLineID: 1 Latest checkpoint's full_page_writes: on Latest checkpoint's NextXID: 0/15960984 Latest checkpoint's NextOID: 4747737 Latest checkpoint's NextMultiXactId: 2982 Latest checkpoint's NextMultiOffset: 6479 Latest checkpoint's oldestXID:1761 Latest checkpoint's oldestXID's DB: 12843 Latest checkpoint's oldestActiveXID: 0 Time of latest checkpoint:Tue 30 Jul 2013 09:57:53 AM EDT Minimum recovery ending location: 0/0 Backup start location:0/0 Backup end location: 0/0 End-of-backup record required:no Current wal_level setting:minimal Current max_connections setting: 100 Current max_prepared_xacts setting: 0 Current max_locks_per_xact setting: 256 Maximum data alignment: 8 Database block size: 8192 Blocks per segment of large relation: 131072 WAL block size: 8192 Bytes per WAL segment:16777216 Maximum length of identifiers:64 Maximum columns in an index: 32 Maximum size of a TOAST chunk:1996 Date/time type storage: 64-bit integers Float4 argument passing: by value Float8 argument passing: by value -- Jesse Denardo On Wed, Jul 31, 2013 at 5:06 PM, Bruce Momjian wrote: > On Wed, Jul 31, 2013 at 12:56:33PM -0400, Alvaro Herrera wrote: > > Bruce Momjian escribió: > > > On Tue, Jul 30, 2013 at 10:17:52AM -0400, Jesse Denardo wrote: > > > > > So, first, this is new in 9.3, and second, it seems the comment "we > need > > > to reset pg_control so that the new server doesn't attempt to read > > > multis older than the cutoff value" is not working. Alvaro, can you > > > comment on this? I think you added this code with this commit: > > > > So it seems. I will have a look. > > Well, the good news is that this is new 9.3 code, this bug was caught > during beta, and pg_upgrade failed visibly, rather than silently. > > -- > Bruce Momjian http://momjian.us > EnterpriseDB http://enterprisedb.com > > + It's impossible for everything to be true. + >
[BUGS] 9.3beta2: Failure to pg_upgrade
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 typesok 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 clusterok 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 &q
