Re: BUG #5599: Vacuum fails due to index corruption issues - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #5599: Vacuum fails due to index corruption issues
Date
Msg-id 23590.1281028781@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #5599: Vacuum fails due to index corruption issues  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: BUG #5599: Vacuum fails due to index corruption issues  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-bugs
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Excerpts from Tom Lane's message of jue ago 05 12:36:24 -0400 2010:
>> Gone?  Looks like it's still there to me.

> I mean the btree code that does the truncation on vacuum full is
> truncated.  There are other uses for truncation, but it doesn't look to
> that they are as problematic ... or are they?

I think what Hitesh reported is a special case of a generic problem.

> Hmm, I guess truncation of heap on lazy vacuum is still a problem
> precisely because page compaction will be forgotten.

Page compaction is the least of it :-(

Imagine that we have some rows at the end of a table, we delete them,
we vacuum before the next checkpoint.  Vacuum decides it can now
truncate away the last pages, but fails to do so.  The original page
state is still on disk, which means we have lost the fact of the
deletion --- the rows are now effectively live again, though their
index entries are probably gone.

In any case, the removal of VACUUM FULL didn't completely disable
shrinking of btree indexes did it?  I don't recall having removed
that.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: BUG #5599: Vacuum fails due to index corruption issues
Next
From: Thom Brown
Date:
Subject: Re: string_agg delimiter having no effect with order by