Re: BUG #5599: Vacuum fails due to index corruption issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Hitesh Bhambhani <hitesh(dot)bhambhani(at)asg(dot)com>, pgsql-bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: BUG #5599: Vacuum fails due to index corruption issues
Date: 2010-08-05 17:19:41
Message-ID: 23590.1281028781@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Pavel Stehule 2010-08-05 17:30:19 Re: string_agg delimiter having no effect with order by
Previous Message Alvaro Herrera 2010-08-05 16:57:46 Re: BUG #5599: Vacuum fails due to index corruption issues

Browse pgsql-hackers by date

  From Date Subject
Next Message Merlin Moncure 2010-08-05 17:26:32 Re: Two different methods of sneaking non-immutable data into an index
Previous Message Chris Browne 2010-08-05 17:10:54 Re: Concurrent MERGE