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

Поиск
Список
Период
Сортировка
От Dirk Lutzebaeck
Тема Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)
Дата
Msg-id 14127.62209.895627.254567@blanc.aeccom.com
обсуждение исходный текст
Ответ на Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)  (Dirk Lutzebaeck <lutzeb@aeccom.com>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Lockhart
Дата:
Сообщение: Re: [HACKERS] pg_dump bug (was Re: [SQL] Slow Inserts Again)
Следующее
От: Dirk Lutzebaeck
Дата:
Сообщение: Re: [HACKERS] major flaw in 6.5beta1??? (UPDATE/INSERT waiting)