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.
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 |