Skip site navigation (1) Skip section navigation (2)

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 18:01:15
Message-ID: 25994.1281031275@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Excerpts from Tom Lane's message of jue ago 05 13:19:41 -0400 2010:
>> 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.

> I see no call to RelationTruncate in the btvacuumscan code, but then it
> was only called in vacuum full before.  I'm not sure how it worked
> previously with only lazy vacuum.  Did we simply leave the pages as free
> for a later extension?

You're right, I misremembered.  That code is just plain gone in 9.0:
http://anoncvs.postgresql.org/cvsweb.cgi/pgsql/src/backend/access/nbtree/nbtree.c.diff?r1=1.174;r2=1.175;f=h

Still, we have a live issue with heap truncation during plain VACUUM.
However, the scope of the problem seems a lot less than I was thinking.
Maybe write-the-buffers-first is a sufficient longterm solution.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-08-05 18:02:44
Subject: Re: Two different methods of sneaking non-immutable data into an index
Previous:From: Josh BerkusDate: 2010-08-05 17:58:30
Subject: Re: pg_stat_user_functions' notion of user

pgsql-bugs by date

Next:From: Tom LaneDate: 2010-08-05 18:25:35
Subject: Re: [HACKERS] Drop one-argument string_agg? (was Re: string_agg delimiter having no effect with order by)
Previous:From: Alvaro HerreraDate: 2010-08-05 17:41:01
Subject: Re: BUG #5599: Vacuum fails due to index corruption issues

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group