Tom Lane wrote:
Richard Huxton <dev@xxxxxxxxxxxx> writes:
Alain Peyrat wrote:
Initial problem:
# pg_dump -O dbname -Ft -f /tmp/database.tar
pg_dump: query to get table columns failed: ERROR: invalid memory alloc
request size 9000688640
After some research, it seems to be related to a corruption of the
database. Running a vacum crashes the db:
-bash-3.00$ vacuumdb -z -a
vacuumdb: vacuuming database "template1"
vacuumdb: vacuuming of database "template1" failed: PANIC: corrupted
item pointer: offset = 3336, size = 20
It would be nice if it's just template1 that is damaged, but I'm not
sure that's the case.
This looks pretty bad, because the above already proves corruption in two
different databases --- there is something wrong somewhere in template1,
and something else wrong somewhere in "dbname" (unless that is actually
template1). It seems likely that there's been widespread damage from
some hardware or filesystem-level misfortune.
FWIW, a look in the source code shows that the 'corrupted item pointer'
message comes only from PageIndexTupleDelete, so that indicates a
damaged index which should be fixable by reindexing.
Tom - could it be damage to a shared system-catalogue, and template1
just the first DB to be vacuumed? It just strikes me as odd that an
index on template1 would be corrupted - assuming it's your typical empty
template1 and is just being connected to during DB creation etc.
Unless, of course, you're looking at genuine on-disk corruption of
unused files/inodes in which it could be anything. Ick :-(
--
Richard Huxton
Archonet Ltd
