Re: Help with Vacuum Failure

"Matthew T. O'Connor" <matthew@zeut.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