pgsql: In B-tree page deletion, clean up properly after page deletion f

Поиск
Список
Период
Сортировка
От Tom Lane
Тема pgsql: In B-tree page deletion, clean up properly after page deletion f
Дата
Msg-id E1bW6L5-0006Al-QG@gemulon.postgresql.org
обсуждение исходный текст
Список pgsql-committers
In B-tree page deletion, clean up properly after page deletion failure.

In _bt_unlink_halfdead_page(), we might fail to find an immediate left
sibling of the target page, perhaps because of corruption of the page
sibling links.  The code intends to cope with this by just abandoning
the deletion attempt; but what actually happens is that it fails outright
due to releasing the same buffer lock twice.  (And error recovery masks
a second problem, which is possible leakage of a pin on another page.)
Seems to have been introduced by careless refactoring in commit efada2b8e.
Since there are multiple cases to consider, let's make releasing the buffer
lock in the failure case the responsibility of _bt_unlink_halfdead_page()
not its caller.

Also, avoid fetching the leaf page's left-link again after we've dropped
lock on the page.  This is probably harmless, but it's not exactly good
coding practice.

Per report from Kyotaro Horiguchi.  Back-patch to 9.4 where the faulty code
was introduced.

Discussion: <20160803.173116.111915228.horiguchi.kyotaro@lab.ntt.co.jp>

Branch
------
REL9_5_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/ee5d1de04f3354c7a87219c2ed481ae51a1bb3b8

Modified Files
--------------
src/backend/access/nbtree/nbtpage.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: pgsql: Teach libpq to decode server version correctly from future serve
Следующее
От: Tom Lane
Дата:
Сообщение: pgsql: In B-tree page deletion, clean up properly after page deletion f