Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting) - Mailing list pgsql-hackers

From Dirk Lutzebaeck
Subject Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)
Date
Msg-id 14127.62209.895627.254567@blanc.aeccom.com
Whole thread Raw
In response to Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)  (Dirk Lutzebaeck <lutzeb@aeccom.com>)
List pgsql-hackers
Tom Lane writes:> Dirk Lutzebaeck <lutzeb@aeccom.com> writes:> > cs=> select envelope from recipient where
envelope=510349;>> [ returns a tuple that obviously fails the WHERE condition ]> > Yipes.  Do you have an index on the
envelopefield, and if so is> it being used for this query?  (Use EXPLAIN to check.)  My guess> is that the index is
corrupted. Dropping and recreating the index> would probably set things right.
 

Yes, thanks, recreating the index cures the problem.
> Of course the real issue is how it got corrupted.  Hiroshi found> an important bug in btree a few days ago, and there
isa discussion> going on right now about lock-manager bugs that might possibly allow> multiple backends to corrupt data
thatthey're concurrently updating.> But I have no idea if either of those explains your problem.
 

Does this mean they can deadlock themselves?  Is this also true for
6.4.2? I probably switch back then.

Thanks, Dirk


pgsql-hackers by date:

Previous
From: Thomas Lockhart
Date:
Subject: Re: [HACKERS] pg_dump bug (was Re: [SQL] Slow Inserts Again)
Next
From: Dirk Lutzebaeck
Date:
Subject: Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)