Re: Possible duplicate release of buffer lock.

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Possible duplicate release of buffer lock.
Дата
Msg-id 26373.1470240033@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Possible duplicate release of buffer lock.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: Possible duplicate release of buffer lock.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Список pgsql-hackers
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> My point here is that if concurrent deletion can't be perfomed by
> the current implement, this while loop could be removed and
> immediately error out or log a message,

>> if (P_ISDELETED(opaque) || opaque->btpo_next != target)
>> {
>> elog(ERROR, "no left sibling of page %d (concurrent deletion?) in \"%s\"",..

That would certainly break things: there are valid cases for the
loop to need to iterate, specifically where the left sibling got
split before we could acquire lock on it.

> or, the while loop at least should stop before overshooting the
> target.

>> while (P_ISDELETED(opaque) || opaque->btpo_next != target)
>> {
>> /* step right one page */
>> leftsib = opaque->btpo_next;
>> _bt_relbuf(rel, lbuf);
>> if (leftsib == target || leftsib == P_NONE)
>> {
>> elog(ERROR, "no left sibling of page %d (concurrent deletion?) in \"%s\"",..

Huh?  Surely that added test condition could never be true because
of the second part of the while() test.
        regards, tom lane



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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Implementing full UTF-8 support (aka supporting 0x00)
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: New version numbering practices