| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "tjk(at)tksoft(dot)com" <tjk(at)tksoft(dot)com> |
| Cc: | pgsql-sql(at)fc(dot)emc(dot)com(dot)ph (pgsql-sql), pgsql-sql(at)postgresql(dot)org |
| Subject: | Re: 7.0.3 BUG |
| Date: | 2000-11-24 23:58:29 |
| Message-ID: | 18195.975110309@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-sql |
"tjk(at)tksoft(dot)com" <tjk(at)tksoft(dot)com> writes:
> Just a wild guess, but I would imagine
> a corrupt (old) index on the userid field would
> cause this kind of behavior.
A corrupt index might be a contributing factor, but it doesn't seem like
it could be the only one. From what I know of the index routines, an
entry should not be returned unless it is confirmed to pass the
indexqual condition. Corrupt indexes can lead to missing output
(because tuples that should match never get visited) but they shouldn't
lead to outputting tuples that don't match.
In any case, we don't even know whether this query used an indexscan...
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ramesh H R | 2000-11-25 07:20:28 | How to set autocommit true/false from a java program |
| Previous Message | tjk@tksoft.com | 2000-11-24 23:51:32 | Re: 7.0.3 BUG |