Ühel kenal päeval, T, 2006-02-28 kell 10:04, kirjutas Hannu Krosing: > Ühel kenal päeval, E, 2006-02-27 kell 15:05, kirjutas Tom Lane: > > Heikki Linnakangas <[EMAIL PROTECTED]> writes: > > > On Mon, 27 Feb 2006, Tom Lane wrote: > > >> This strikes me as a fairly bad idea, because it makes VACUUM dependent > > >> on correct functioning of user-written code --- consider a functional > > >> index involving a user-written function that was claimed to be immutable > > >> and is not. > > > > > If the user-defined function is broken, you're in more or less trouble > > > anyway. > > > > Less. A non-immutable function might result in lookup failures (not > > finding the row you need) but not in database corruption, which is what > > would ensue if VACUUM fails to remove an index tuple.
Or do you man that an index entry pointing to a non-existing tuple is "corruption" ? It would be realtively easy to teach index access method to just ignore (or even delete) the dangling index entries. > Arguably the database is *already* broken once one has used a > non-immutable function in index ops. > > "Failing to remove" is a condition that is easily detected, so one can > flag the operator class as lossy (RECHECK) and actually fix that > brokenness. Ok, maybe not fix but alleviate - you wont get any non-matching tuples, but there still remains the possibility to get the sam tuple twice. ------------ Hannu ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
