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.
|
Список | 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 по дате отправления: