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@xxxxxxxxxxxx> 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
