Re: _bt_split(), and the risk of OOM before its critical section
От | Peter Geoghegan |
---|---|
Тема | Re: _bt_split(), and the risk of OOM before its critical section |
Дата | |
Msg-id | CAH2-WzkCRBLA5wYcy9p_bKAD1anmMTJLix0BGFuh2qmu3=k0-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: _bt_split(), and the risk of OOM before its critical section (Peter Geoghegan <pg@bowt.ie>) |
Список | pgsql-hackers |
On Mon, May 6, 2019 at 5:15 PM Peter Geoghegan <pg@bowt.ie> wrote: > VACUUM asserts P_FIRSTDATAKEY(opaque) > PageGetMaxOffsetNumber(page) > within _bt_mark_page_halfdead(), but doesn't test that condition in > release builds. This means that the earliest modifications of the > right page, before the high key PageAddItem(), are enough to cause a > subsequent "failed to re-find parent key" failure in VACUUM. Merely > setting the sibling blocks in the right page special area is enough to > cause VACUUM to refuse to run. To be clear, my point here was that this confirms what you said about PageGetTempPage() failing after _bt_getbuf() has initialized the buffer for the new right page -- that is not in itself a problem. However, practically any other change to the right page that might occur before an error is raised within _bt_split() is a problem -- not just adding a new item. (You were right about that, too.) -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: