Re: 32-bit to 64-bit migration screwup

From: "Phillip Smith" <phillip(dot)smith(at)weatherbeeta(dot)com(dot)au>
To: "'David Young'" <randomfire(at)gmail(dot)com>, <pgsql-admin(at)postgresql(dot)org>
Subject: Re: 32-bit to 64-bit migration screwup
Date: 2007-10-26 06:07:46
Message-ID: 011601c81796$874071e0$9b0014ac@wbaus090
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

I'm assuming you've made a jump in database version - ie, 7.4 to 8.2 or
similar.

You need to use initdb to create new database files, then pg_dumpall on the
old system to dump the data out of the old before importing to the new. Make
sure you use pg_dumpall from the new version to dump the data from the old
database.

-----Original Message-----
From: pgsql-admin-owner(at)postgresql(dot)org
[mailto:pgsql-admin-owner(at)postgresql(dot)org] On Behalf Of David Young
Sent: Friday, 26 October 2007 15:52
To: pgsql-admin(at)postgresql(dot)org
Subject: [ADMIN] 32-bit to 64-bit migration screwup

All,

I was hoping someone can help me fix a big blunder. I recently bought a new
system to replace the old one. The new system is running 64bit linux and
the old one 32bit. I installed PG 64-bit and tried to bring the old
database back up. Even though I'm running the same version of PG, it is
giving me an error when I try to start it back up. below is the message
from pgstartup.log. It looks like it doesn't recognize the control file
anymore.

Am I screwed? I don't have the old system anymore and I didn't do a dump.
I figure if I'm running the same version of PG, the data will come back up
correctly. If someone can help me out of this jam, I would greatly
appreciate it.

Thanks,

David

------------------pgstartup.log---------------

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 locale en_US.UTF-8.
The default database encoding has accordingly been set to UTF8.

fixing permissions on existing directory /var/lib/pgsql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers/max_fsm_pages ... 24MB/153600
creating configuration files ... ok
creating template1 database in /var/lib/pgsql/data/base/1 ... ok
initializing pg_authid ... ok
initializing dependencies ... ok
creating system views ... ok
loading system objects' descriptions ... ok
creating conversions ... ok
setting privileges on built-in objects ... ok
creating information schema ... ok
vacuuming database template1 ... ok
copying template1 to template0 ... ok
copying template1 to postgres ... ok

Success. You can now start the database server using:

/usr/bin/postgres -D /var/lib/pgsql/data
or
/usr/bin/pg_ctl -D /var/lib/pgsql/data -l logfile start

LOG: logger shutting down
LOG: logger shutting down
LOG: logger shutting down
LOG: logger shutting down
LOG: logger shutting down
FATAL: incorrect checksum in control file
FATAL: incorrect checksum in control file
FATAL: incorrect checksum in control file

THINK BEFORE YOU PRINT - Save paper if you don't really need to print this

*******************Confidentiality and Privilege Notice*******************

The material contained in this message is privileged and confidential to
the addressee. If you are not the addressee indicated in this message or
responsible for delivery of the message to such person, you may not copy
or deliver this message to anyone, and you should destroy it and kindly
notify the sender by reply email.

Information in this message that does not relate to the official business
of Weatherbeeta must be treated as neither given nor endorsed by Weatherbeeta.
Weatherbeeta, its employees, contractors or associates shall not be liable
for direct, indirect or consequential loss arising from transmission of this
message or any attachments
e-mail.

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Devrim GÜNDÜZ 2007-10-26 06:15:49 Re: 32-bit to 64-bit migration screwup
Previous Message David Young 2007-10-26 05:52:06 32-bit to 64-bit migration screwup