Thread: 7.0.3 BUG

SELECT is returning bogus data.

migrate=# select version();                           version
---------------------------------------------------------------PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc
2.95.3
(1 row)

migrate=# select userid from users where userid = 'reynan@yahoo.com';      userid
---------------------reynan@yahoo.comadmin
(2 rows)
migrate=# \d users                                     Table "users"   Attribute     |     Type     |
    Modifier
 
------------------+--------------+--------------------------------------------------------userrefkey       | integer
 | not null default
 
nextval('users_userrefkey_seq'::text)userid           | varchar(128) | not nullpassword1        | char(20)     | not
nullpassword2       | char(50)     |type             | char(10)     | not nullpartneremail     | varchar(128)
|adminlastname   | char(40)     | not nulladminfirstname   | char(40)     | not nulladminaddress1    | char(80)     |
notnulladminaddress2    | char(80)     |admincity        | char(80)     | not nulladminstateprov   | char(40)
|admincountrycode| char(2)      | not nulladminpostalcode  | char(10)     |adminphone       | char(20)     |adminfax
    | char(20)     |checkpayableto   | char(80)     | not nullcreatedate       | timestamp    | not null default
now()lastaccessdate  | timestamp    |lastmodifieddate | timestamp    |
 
Indices: users_pkey,        users_userid_key   

"pgsql-sql" <pgsql-sql@fc.emc.com.ph> writes:
> migrate=# select userid from users where userid = 'reynan@yahoo.com';
>        userid
> ---------------------
>  reynan@yahoo.com
>  admin
> (2 rows)

That's a tad, um, startling :-(

However, you haven't given us nearly enough information to have a shot
at figuring out what's going on.
        regards, tom lane

Just a wild guess, but I would imagine 
a corrupt (old) index on the userid field would
cause this kind of behavior.

You could test this by dropping the index and
then rebuilding it.


Troy


> 
> "pgsql-sql" <pgsql-sql@fc.emc.com.ph> writes:
> > migrate=# select userid from users where userid = 'reynan@yahoo.com';
> >        userid
> > ---------------------
> >  reynan@yahoo.com
> >  admin
> > (2 rows)
> 
> That's a tad, um, startling :-(
> 
> However, you haven't given us nearly enough information to have a shot
> at figuring out what's going on.
> 
>             regards, tom lane
> 

"tjk@tksoft.com" <tjk@tksoft.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