Re: [HACKERS] Resurrecting per-page cleaner for btree

On Jul 26, 2006, at 10:29 AM, Tom Lane wrote:
> Gregory Stark <gsstark(at)mit(dot)edu> writes:
>> ... Well it's not like the existing vacuum checks for this.
>
> Right, that's exactly why the patch works at all. But the point
> here is
> that the existing vacuum does not rely on re-computing index keys; all
> it cares about is matching TIDs. The retail-vacuum idea depends on
> the
> assumption that you can look at the tuple and re-compute the same
> index
> keys that you computed the first time; which is an assumption much
> shakier than the assumption that TID comparison works. (In fact, it's
> trivial to see how user-defined functions that are mislabeled
> immutable
> could make this fail.) So retail vacuum without any cross-check that
> you got all the index tuples is a scary proposition IMHO.

Are there other cases that could cause a problem besides mislabeled
user function indexes (a case I don't feel we need to protect
against) and bugs in core?

If we don't worry about users who can't figure out what immutable
means, we should be able to cover core bugs by having the buildfarm
occasionally do long-running pg_bench (or some other workload) runs
with autovacuum turned on. Knowing what autovacuum is set to, we can
calculate approximately how much dead/empty space should exist in
indexes, and make sure we're within reason (though this might mean
having a mode that disables deleting known-dead tuples before
splitting a page). Another possibility would be actually inspecting
the indexes for invalid entries.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461