From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Dirk Lutzebaeck <lutzeb(at)aeccom(dot)com>, pgsql-bugs(at)postgreSQL(dot)org |
Subject: | Re: [BUGS] vacuum analyze corrupts db with larger tuples (< 8k)] |
Date: | 2000-01-04 19:45:08 |
Message-ID: | 200001041945.OAA20560@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> Dirk Lutzebaeck <lutzeb(at)aeccom(dot)com> writes:
> > ok, here is what I have found out on 6.5.3, Linux 2.2.10:
> > [ make table with a bunch of almost-5K varchar fields ]
> > # vacuumdb --analyze test
> > ERROR: Tuple is too big: size 9604
> > vacuumdb: database vacuum failed on test.
>
> 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 had already patched this in current sources, by the expedient of not
> trying to store a pg_statistic tuple at all if it's too big. (Then
> you don't get stats for that particular column, but the stats probably
> wouldn't be useful anyway.)
>
> I suppose I should make up a back-patch for REL6_5 with this fix.
Oh, good we know the cause. Seems we should wait for 7.0 for this.
--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Karl DeBisschop | 2000-01-04 20:01:32 | Re: [BUGS] problem creating index in 6,5,3 |
Previous Message | Olivier PRENANT | 2000-01-04 18:07:38 | Re: [BUGS] Date calc bug |