Re: [ADMIN] pg_dumpall failure - could not access status of transaction
I wrote: I am attempting to get a handle on the corruption that caused the following error... After a bit more digging I found a couple of old messages that helped - http://archives.postgresql.org/pgsql-admin/2004-01/msg00258.php The last tuple that is valid is (3, 123) and looking at record 3 in the corresponding file, it appears to be the last entry in that record and it has no errors. Assuming that the next tuple will be in record 4 and dumping it, results in the first 32 items having the error Error: Computed header length not equal to header size. Computed 28 Header: 0 or similar. Is there any likelihood this is a pg problem (it is running 8.1.4 on ubuntu 6.06 server)? Is upgrading to 8.2.x worthwhile or is it more likely to be a h/w issue? Note that the same box had 'invalid page header' issues around 4 weeks ago - although these have not occurred since the supplier replaced the shared memory video card with a non-shared card 2 weeks ago. Basically, it would be good to be able to go to the supplier and say there is definitely a h/w issue here, so any help in this area would be great. Thanks Robert ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [ADMIN] pg_dumpall failure - could not access status of transaction
Robert Leftwich wrote: pg_dump: Error message from server: ERROR: could not access status of transaction 3183024 DETAIL: could not open file pg_clog/0003: No such file or directory If your database system has already experienced on the order of 3183024 transactions, then you should wonder where that file went. Otherwise you probably have garbage on disk, pointing to a transaction that hasn't happened yet. This is usually hardware trouble in any case, unless you have actually deleted the file manually. The alternative is that your database system has already seen more than 2^32 transactions and you have hit some bug in the transaction wraparound, but that would be much less likely than the above cases. I'm (obviously) lost here - what is the correct way to track down the appropriate file and record to point pg_filedump at to view any corruption? Look for something that contains 3183024 as a four-byte integer. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [ADMIN] pg_dumpall failure - could not access status of transaction
Robert Leftwich [EMAIL PROTECTED] writes: On Fri, 02 Feb 2007 21:21:47 -0500, Tom Lane [EMAIL PROTECTED] said: Also, can you show us the pg_filedump output for the page of pg_description you think is trashed? I find -i -f options give the most useful output usually. [ dump snipped ] Yeah, the last part of that page has been trashed --- mostly zeroes, but there's a bit with an odd data pattern that doesn't make much sense to me: 1a3c: d09b3000 b89b3000 a09b3000 889b3000 ..0...0...0...0. 1a4c: 709b3000 589b3000 409b3000 289b3000 [EMAIL PROTECTED](.0. 1a5c: 109b3000 f89a3000 e09a3000 c89a3000 ..0...0...0...0. 1a6c: b09a3000 989a3000 809a3000 689a3000 ..0...0...0.h.0. This seems like it could indicate either a hardware or operating-system flake-out. Have you tried running hardware diagnostic tests on the machine? 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
