On Jul 26, 2006, at 10:29 AM, Tom Lane wrote:
Gregory Stark <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
