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

Reply via email to