Re: [BUGS] vacuum analyze corrupts db with larger tuples (< 8k)

I wrote:
> Ohhh ... I know what's going on. The oversize tuple is the one that
> VACUUM is attempting to store in pg_statistic, containing the min and
> max values for your varchar column. In this example, both the min and
> max are just shy of 5K characters, so the pg_statistic tuple is too
> big to fit on a page.

I have applied the attached patch to the REL6_5 branch. (There is
already similar code in the current branch.) I'm afraid it won't
help you recover from an already-corrupted pg_statistic table, though.

regards, tom lane

*** src/backend/commands/vacuum.c.orig Wed Aug 25 08:01:45 1999
--- src/backend/commands/vacuum.c Tue Jan 4 12:15:17 2000
***************
*** 2405,2414 ****
stup = heap_formtuple(sd->rd_att, values, nulls);

/* ----------------
! * insert the tuple in the relation and get the tuple's oid.
* ----------------
*/
! heap_insert(sd, stup);
pfree(DatumGetPointer(values[3]));
pfree(DatumGetPointer(values[4]));
pfree(stup);
--- 2405,2425 ----
stup = heap_formtuple(sd->rd_att, values, nulls);

/* ----------------
! * Watch out for oversize tuple, which can happen if
! * both of the saved data values are long.
! * Our fallback strategy is just to not store the
! * pg_statistic tuple at all in that case. (We could
! * replace the values by NULLs and still store the
! * numeric stats, but presently selfuncs.c couldn't
! * do anything useful with that case anyway.)
* ----------------
*/
! if (MAXALIGN(stup->t_len) <= MaxTupleSize)
! {
! /* OK to store tuple */
! heap_insert(sd, stup);
! }
!
pfree(DatumGetPointer(values[3]));
pfree(DatumGetPointer(values[4]));
pfree(stup);