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

Re: Dead Space Map

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Dead Space Map
Date: 2006-02-28 08:17:41
Message-ID: 1141114661.3775.32.camel@localhost.localdomain (view raw or flat)
Thread:
Lists: pgsql-hackers
Ü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 <hlinnaka(at)iki(dot)fi> 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



In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2006-02-28 10:38:51
Subject: Re: Dead Space Map
Previous:From: Hannu KrosingDate: 2006-02-28 08:12:24
Subject: Re: Dead Space Map

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