Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)

From: Michael Davis <Michael(dot)Davis(at)tvguide(dot)com>
To: Dirk Lutzebaeck <lutzeb(at)aeccom(dot)com>
Cc: Tom Lane <Tgl(at)Sss(dot)Pgh(dot)Pa(dot)Us>, Hackers(at)Postgresql(dot)Org
Subject: Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)
Date: 1999-05-05 14:20:40
Message-ID: 199905051427.KAA76248@hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Your e-mail did not arrive at its intended destination. You need to
send it to Michael J. Davis, not Michael Davis

From: Dirk Lutzebaeck <lutzeb @ aeccom.com> on 05/05/99 03:30 AM
To: Tom Lane <tgl @ sss.pgh.pa.us>@SMTP(at)EXCHANGE
cc: hackers @ postgreSQL(dot)org(at)SMTP@EXCHANGE
Subject: Re: [HACKERS] major flaw in 6.5beta1???
(UPDATE/INSERT waiting)

Tom Lane writes:
> Dirk Lutzebaeck <lutzeb(at)aeccom(dot)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 envelope field, 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 is a
discussion
> going on right now about lock-manager bugs that might possibly
allow
> multiple backends to corrupt data that they'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

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Davis 1999-05-05 14:21:00 Re: [HACKERS] Small improvement
Previous Message Michael Davis 1999-05-05 14:19:38 Re: [HACKERS] posmaster failed under high load