Restoring a Full Cluster on a Different Architecture (32 x 64)

From: "Rodrigo Hjort" <rodrigo(dot)hjort(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Restoring a Full Cluster on a Different Architecture (32 x 64)
Date: 2006-03-13 17:56:00
Message-ID: 731083980603130956l369a4082s@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear PostgreSQL Hackers,

We got a PG 8.1 on a Debian 64 bits, which does a full backup (PITR) daily.
Then we installed a Debian 32 bits (actually, it's on VMWare) and wanted to
restore the previous PG cluster on it.
As there are a lot of indexes, specially GiST, "pg_dump" and "pg_restore"
are not viable - will take a lot of time!

Well, the fact is that we've got the message below on "postmaster" start
attempt:

"WARNING: Calculated CRC checksum does not match value stored in file.
Either the file is corrupt, or it has a different layout than this program
is expecting. The results below are untrustworthy."

As the architecture on both Linuxes are different (32 and 64 bits), I think
"PGDATA/global/pg_control" might contains 64 bit data such that the 32 bits
binary won't recognize or even mispell it. Am I right?

What could be done in order to fix it? Is there any kind of application to
translate it or the only solution was to "pg_dumpall" and "pg_restore" the
cluster?

**********************************************************************************************

postgres(at)pga1:/tmp/lala/global$ uname -a
Linux pga1 2.6.8-2-686 #1 Tue Aug 16 13:22:48 UTC 2005 i686 GNU/Linux

postgres(at)pga1:/tmp/lala/global$ pg_controldata /var/lib/postgresql/8.1/main/
WARNING: Calculated CRC checksum does not match value stored in file.
Either the file is corrupt, or it has a different layout than this program
is expecting. The results below are untrustworthy.

pg_control version number: 812
Catalog version number: 200510211
Database system identifier: 4883914971069546458
Database cluster state: in production
pg_control last modified: Wed 31 Dec 1969 09:00:00 PM BRT
Current log file ID: 1142136269
Next log file segment: 0
Latest checkpoint location: 1/30
Prior checkpoint location: 1/2F71B630
Latest checkpoint's REDO location: 1/2F71B5E0
Latest checkpoint's UNDO location: 1/2F71B630
Latest checkpoint's TimeLineID: 0
Latest checkpoint's NextXID: 0
Latest checkpoint's NextOID: 1
Latest checkpoint's NextMultiXactId: 36239847
Latest checkpoint's NextMultiOffset: 1819439
Time of latest checkpoint: Wed 31 Dec 1969 09:00:11 PM BRT
Maximum data alignment: 25
Database block size: 0
Blocks per segment of large relation: 8
Bytes per WAL segment: 0
Maximum length of identifiers: 0
Maximum columns in an index: 1093850759
Date/time type storage: 64-bit integers
Maximum length of locale name: 131072
LC_COLLATE:
LC_CTYPE:

**********************************************************************************************

pgsql01:~# uname -a
Linux pgsql01 2.6.8-11-em64t-p4-smp #1 SMP Mon Oct 3 00:07:51 CEST 2005
x86_64 GNU/Linux

pgsql01:~# /usr/lib/postgresql/8.1/bin/pg_controldata /pg/data/
pg_control version number: 812
Catalog version number: 200510211
Database system identifier: 4883914971069546458
Database cluster state: in production
pg_control last modified: Mon Mar 13 14:19:42 2006
Current log file ID: 1
Next log file segment: 51
Latest checkpoint location: 1/3289F8E0
Prior checkpoint location: 1/32827710
Latest checkpoint's REDO location: 1/3289F8E0
Latest checkpoint's UNDO location: 0/0
Latest checkpoint's TimeLineID: 1
Latest checkpoint's NextXID: 37253588
Latest checkpoint's NextOID: 1819439
Latest checkpoint's NextMultiXactId: 11
Latest checkpoint's NextMultiOffset: 25
Time of latest checkpoint: Mon Mar 13 14:19:42 2006
Maximum data alignment: 8
Database block size: 8192
Blocks per segment of large relation: 131072
Bytes per WAL segment: 16777216
Maximum length of identifiers: 64
Maximum columns in an index: 32
Date/time type storage: 64-bit integers
Maximum length of locale name: 128
LC_COLLATE: pt_BR
LC_CTYPE: pt_BR

**********************************************************************************************

Regards,

Rodrigo Hjort
GTI - Projeto PostgreSQL
CELEPAR - Cia de Informática do Paraná
http://www.pr.gov.br

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2006-03-13 18:19:47 Re: Transaction eating up all RAM
Previous Message Peter 2006-03-13 17:43:25 Re: Transaction eating up all RAM