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

From Alvaro Herrera
Subject Re: BUG #5599: Vacuum fails due to index corruption issues
Date
Msg-id 1281027356-sup-6865@alvh.no-ip.org
Whole thread Raw
In response to Re: BUG #5599: Vacuum fails due to index corruption issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5599: Vacuum fails due to index corruption issues  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Excerpts from Tom Lane's message of jue ago 05 12:36:24 -0400 2010:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > Excerpts from Tom Lane's message of jue ago 05 11:06:57 -0400 2010:
> >> 1. Write the dirty buffers before dropping them.  Kind of ugly from a
> >> performance viewpoint, but simple and safe.
>
> > I think "simple" is good, considering that this code is gone in 9.0 and
> > HEAD.  IMHO investing too much effort on this problem is not worth it.
>
> 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?

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

> > Perhaps it'd be good to come up with a better solution for HEAD:
>
> Yeah, the panic-on-replay aspect is troublesome.  I feel like we need a
> rethink here.  But I agree that solution #1 is the only one that feels
> safe enough for backpatching.

--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5602: Recovering from Hot-Standby file backup leads to the currupted indexes
Next
From: Tom Lane
Date:
Subject: Re: BUG #5599: Vacuum fails due to index corruption issues