Re: _bt_split(), and the risk of OOM before its critical section - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: _bt_split(), and the risk of OOM before its critical section
Date
Msg-id CAH2-WzkCRBLA5wYcy9p_bKAD1anmMTJLix0BGFuh2qmu3=k0-Q@mail.gmail.com
Whole thread Raw
In response to Re: _bt_split(), and the risk of OOM before its critical section  (Peter Geoghegan <pg@bowt.ie>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: _bt_split(), and the risk of OOM before its critical section
Next
From: Michael Paquier
Date:
Subject: Re: reindexdb & clusterdb broken against pre-7.3 servers