Re: Nasty btree deletion bug

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: Nasty btree deletion bug
Дата
Msg-id 4540CD7F.30909@enterprisedb.com
обсуждение исходный текст
Ответ на Re: Nasty btree deletion bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Nasty btree deletion bug  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> I wrote:
>> I've been analyzing Ed L's recent report of index corruption:
>> http://archives.postgresql.org/pgsql-general/2006-10/msg01183.php

Auch. That's nasty indeed.

> So I think the rule needs to be "don't delete the rightmost child unless
> it's the only child, in which case you can delete the parent too --- but
> the same restriction must be observed at the next level up".
> ....
> The concept of a half-dead page would remain, but it'd be a transient
> state that would normally only persist for a moment between atomic
> page-delete actions.  If we crash between two such actions, the
> half-dead page would remain present, but would be found and cleaned up
> by the next VACUUM.  In the meantime it wouldn't cause any problem
> because the keyspace it gives up will belong to a sibling of the same
> parent at whatever level the delete is ultimately supposed to stop at,
> and so inserts and even splits in that keyspace won't create an
> inconsistency.  

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/

> ...
> 
> Comments?  Have I missed anything?

It took me a lot of time with pen and paper to understand the issue. And 
I'm not sure I still understood it fully. The logic is very complex, 
which is bad for maintainability in itself :(.

--   Heikki Linnakangas  EnterpriseDB   http://www.enterprisedb.com


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

Предыдущее
От: Volkan YAZICI
Дата:
Сообщение: Re: pg_get_domaindef()
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Nasty btree deletion bug