> Actually Tom, i am not able to understand that completely. But what you are
> saying that in the current scenario, when there is a broken data type based
> index, then it will return no results, but never will return wrong results.
> So never the update will corrupt the heap data. But i take it as you say
> (please, correct me, if i am wrong).
> But even returning no results might lead to failures in unqiue checks.
> While i inserting, i try to check whether a particular data is already
> inserted and if it returns no results, then it will go ahead and insert the
> data assuming that the unique check has passed, while in reality it has
> Wait a minute. Bingo!!!! So for unique checks we are already going to
> index from Heap. So it is the same thing i am doing with Thick index. So if
> we can trust our current unique checks, then we should trust the Thick
> Thanks Tom!!! for having this good conversation....
> I think this broken data type problem / volatile function issue has to be
> resolved for the current index, if we advocate to stop the thick index.
> Can i get a feedback from Tom / Heikki regarding my observation?
In response to
pgsql-hackers by date
|Next:||From: Jaime Casanova||Date: 2010-02-27 06:08:39|
|Subject: Re: Correcting Error message|
|Previous:||From: Greg Smith||Date: 2010-02-27 05:10:50|
|Subject: Re: Lock Wait Statistics (next commitfest)|