From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Bernhard D Rohrer <graylion(at)sm-wg(dot)net> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: pg recovery |
Date: | 2008-01-02 17:39:03 |
Message-ID: | 17137.1199295543@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Bernhard D Rohrer <graylion(at)sm-wg(dot)net> writes:
> Tom Lane wrote:
>> I think you've got a cross-version problem, as in the database is really
>> PG 8.0 or earlier but you're trying to run 8.1 against it. What is in
>> the PG_VERSION file? Have you done "pg_resetxlog -f", and if so do you
>> have the original pg_control file to put back?
> as for the versions see for yourself:
> root(at)collab:/home/adminlion# cat /var/lib/postgresql/8.1/main/PG_VERSION
> 8.1
> root(at)collab:/home/adminlion# cat
> /olddrive/var/lib/postgresql/8.1/main/PG_VERSION
> 8.1
Hmmm ... but it sure looks like the values are offset a few fields from
where they belong ... [ meditates awhile... ] Ah, I've sussed it: the
pg_controldata output you showed can be explained exactly by the
assumption that this copy of pg_controldata thinks time_t is 64 bits
wide, where the pg_control file actually has 32-bit-wide time_t fields.
That explains both the ridiculously large dates (quite impossible for
32-bit time_t's) and the offsetting of the following fields.
So the short answer is probably that you're trying to use a 64-bit build
of Postgres against a 32-bit database. You need to get a matching build.
(We really need to stop using time_t in pg_control.h ...)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Koczan | 2008-01-02 17:46:15 | best practices for separating data and logs |
Previous Message | Andrew Sullivan | 2008-01-02 17:05:56 | Re: reconfiguring diskspace while upgrading to 8.2.5 |