Re: Help with Vacuum Failure

"Matthew T. O'Connor" <matthew(at)zeut(dot)net> writes:
> cms_beau=# vacuum hits; (It works without the analyze phase of backup.)
> VACUUM
> cms_beau=# VACUUM verbose analyze hits;
> NOTICE: --Relation hits--
> NOTICE: Pages 8389: Changed 0, reaped 2, Empty 0, New 0; Tup 834575: Vac 0,
> Keep/VTL 4/4, Crash 0, UnUsed 6, MinLen 52, MaxLen 121; Re-using:
> Free/Avail. Space 376/64; EndEmpty/Avail. Pages 0/1. CPU 0.34s/0.05u sec.
> NOTICE: Index hits_id_key: Pages 1831; Tuples 834575: Deleted 0. CPU
> 0.11s/0.56u sec.
> NOTICE: Rel hits: Pages: 8389 --> 8389; Tuple(s) moved: 0. CPU 0.00s/0.00u
> sec.
> NOTICE: --Relation pg_toast_6742393--
> NOTICE: Pages 0: Changed 0, reaped 0, Empty 0, New 0; Tup 0: Vac 0,
> Keep/VTL 0/0, Crash 0, UnUsed 0, MinLen 0, MaxLen 0; Re-using: Free/Avail.
> Space 0/0; EndEmpty/Avail. Pages 0/0. CPU 0.00s/0.00u sec.
> NOTICE: Index pg_toast_6742393_idx: Pages 1; Tuples 0. CPU 0.00s/0.00u sec.
> NOTICE: Analyzing...
> ERROR: MemoryContextAlloc: invalid request size 4294079565
> cms_beau=#

This looks like you have corrupted data in your table --- specifically,
a variable-length value with a bogus length word. If so, you'll get a
similar error during any attempt to access the particular value or row
that's corrupted. A quick check of this theory is to try to pg_dump
the table --- if it fails with the same sort of error, then you have
a problem.

> PostgreSQL 7.1.2 on i686-pc-linux-gnu, compiled by GCC 2.96

2.96? AFAICT 2.95.3 is the latest official release of GCC.

regards, tom lane