From: | Bernhard D Rohrer <graylion(at)sm-wg(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-admin(at)postgresql(dot)org |
Subject: | Re: pg recovery |
Date: | 2008-01-02 18:31:14 |
Message-ID: | 477BD872.8070405@sm-wg.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
Tom Lane wrote:
> 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
exactly - I am currently installing a 32bit dapper on a VM in order to
do the migration
thanks muchly :)
Bernhard
--
Graylion's Fetish & Fashion Store
Goth and Kinky Boots, Clothing and Jewellery
http://www.graylion.net
From | Date | Subject | |
---|---|---|---|
Next Message | Naomi Walker | 2008-01-02 18:48:44 | Re: Performance tuning... |
Previous Message | Tom Lane | 2008-01-02 18:10:01 | Re: best practices for separating data and logs |