Re: Nasty btree deletion bug

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Nasty btree deletion bug
Дата
Msg-id 21061.1161877649@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Nasty btree deletion bug  (Heikki Linnakangas <heikki@enterprisedb.com>)
Ответы Re: Nasty btree deletion bug  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
Re: Nasty btree deletion bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Heikki Linnakangas <heikki@enterprisedb.com> writes:
> I don't understand how this "in the meantime" thing works. I tried to 
> work out a step-by-step example, could you take a look at it? See
> http://users.tkk.fi/~hlinnaka/pgsql/btree-deletion-bug/

[ looks at that for a bit... ]  Yeah, you're right.  Once the deletion
is completed, the F lower-bound key will disappear from the grandparent,
which would restore consistency --- but we could have already delivered
wrong search answers, so that won't do.

In theory, given a slow-enough-moving VACUUM process, this could happen
even without a crash.  So I think that means we have to go over to the
other plan of locking everything all the way up to the top of the
deletion before we start doing it --- and also, we'll need crash
recovery logic to complete the incomplete deletion, same as for
incomplete inserts.  Yech --- more code than I was hoping to have to
write, and more concurrency hit too.

OTOH we might be able to get rid of the notion of "half dead", which
would allow some simplifications.

Thanks for taking a close look!
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Nasty btree deletion bug
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Replication documentation addition