Re: invalid page header

OK.  The saga continues, everything is a little bit more clear, but at
the same time a lot more confusing.

Today i wanted to reproduce the problem again.  And guess what? A vacuum
of the database went thru without any problems.

I dump the block i was having problems with yesterday.  It doesn't
report an invalid header anymore and it contains other data!!!

Turns out the data that was returned yesterday belongs to another database!

Some more detail about the setup.  This server runs 2 instances of
postgresql.  One production instance which is version 8.0.3.  And
another testing instance installed in a different folder which runs
version 8.1.3  Am I wrong thinking this setup ought to work?

Both instances use completely seperated data folders.

So the first dump returned data that actually belongs to an 8.0.3
database (that runs fine).  And today without _any_ intervention that
same block returns the correct data and the complete database is fine.

Where is the problem?
    The fact that i'm running 2 different instances?
    Cache on raid controller messing up?
    Some strange voodoo?




Jo De Haes wrote:
> Ok,  So we reran everything and got the same error message again, now
> i'm able to reproduce it.

>
> Tom Lane wrote:
>
>> Jo De Haes <jo.de_nospam_haes@indicator.be> writes:
>>
>>> I asked the developper to delete all imported data again an restart
>>> the import.  This import crashed again with the same error but this
>>> time on another block.
>>
>>
>>
>>> 2006-03-27 00:15:25.458 CESTERROR:  XX001: invalid page header in
>>> block 48068 of relation "dunn_main"
>>> 2006-03-27 00:15:25.458 CESTCONTEXT:  SQL statement "SELECT  phone
>>> FROM dunn_main WHERE source_id =  $1  AND duns =  $2 "
>>>         PL/pgSQL function "proc_dunn" line 29 at select into variables
>>> 2006-03-27 00:15:25.458 CESTLOCATION:  ReadBuffer, bufmgr.c:257
>>> 2006-03-27 00:15:25.458 CESTSTATEMENT:  SELECT proc_dunn ('J M
>>> Darby','TA4 3BU','215517942','1','01','S',NULL,'0219',156,1
>>> 54,387166)
>>
>>
>>
>>> But again, when i do the 'SELECT proc_dunn ('J M Darby','TA4
>>> 3BU','215517942','1','01','S',NULL,'0219',156,1
>>> 54,387166)' statement now, it works without errors.
>>
>>
>>
>> That is *really* strange.  Are you certain that the function is
>> examining the same table you are?  I'm wondering about multiple
>> similarly-named tables in different schemas, or something like that.
>>
>>
>>> If I would like to dump block 48068 now with pg_dumpfile, how do i
>>> know which file this block belongs to?
>>
>>
>>
>> See
>> http://www.postgresql.org/docs/8.1/static/storage.html
>> and/or use contrib/oid2name.
>>
>>             regards, tom lane
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 9: In versions below 8.0, the planner will ignore your desire to
>>        choose an index scan if your joining column's datatypes do not
>>        match
>>