From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: _bt_split(), and the risk of OOM before its critical section |
Date: | 2019-05-07 00:26:09 |
Message-ID: | CAH2-WzkCRBLA5wYcy9p_bKAD1anmMTJLix0BGFuh2qmu3=k0-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, May 6, 2019 at 5:15 PM Peter Geoghegan <pg(at)bowt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-05-07 00:46:07 | Re: reindexdb & clusterdb broken against pre-7.3 servers |
Previous Message | Peter Geoghegan | 2019-05-07 00:15:30 | Re: _bt_split(), and the risk of OOM before its critical section |