Tom Lane wrote:
> Richard Huxton <dev@archonet.com> 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