aboutsummaryrefslogtreecommitdiff
path: root/src/backend/utils/adt/enum.c
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2016-08-06 14:28:37 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2016-08-06 14:28:37 -0400
commite89526d4f3567c58c2a69fa1b1d9e44df89349fb (patch)
tree046e75577a4dccdf7e24ab066b155883b57f4e9a /src/backend/utils/adt/enum.c
parent69dc5ae408f68c302029a6b43912a2cc16b1256c (diff)
downloadpostgresql-e89526d4f3567c58c2a69fa1b1d9e44df89349fb.tar.gz
postgresql-e89526d4f3567c58c2a69fa1b1d9e44df89349fb.zip
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>
Diffstat (limited to 'src/backend/utils/adt/enum.c')
0 files changed, 0 insertions, 0 deletions