Re: Orphan page in _bt_split

On Mon, Sep 1, 2025 at 3:04 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> There's just no reason to think that we'd ever be able to tie back one
> of these LOG messages from VACUUM to the problem within _bt_split.
> There's too many other forms of corruption that might result in VACUUM
> logging this same error (e.g., breaking changes to a glibc collation).

Thinking about this some more, I guess it's generally fairly unlikely
that VACUUM would actually even attempt to delete such a page. The
only reason why it happens with Konstantin's test case is because the
whole inserting transaction aborts, leaving behind many garbage tuples
that VACUUM will remove, leading to an empty page. Without that,
VACUUM won't think to even try to delete a left over junk right
sibling page.

> An important case where this weakness will make life worse for users
> is a checksum failure against the existing right sibling page -- since
> those are not once off, transient errors (unlike, say, OOMs). Once you
> have an index page with a bad checksum, there's a decent chance that
> the application will attempt to insert onto the page to the immediate
> left of that bad page. That'll trigger a split, sooner or later.

Also rethinking this aspect: a checksum failure probably *isn't* going
to make much difference. Since that'll also cause bigger problems for
VACUUM than logging one of these "failed to re-find parent key"
messages.

I still think that we should do something about this. Not sure how I
feel about backpatching just yet.

--
Peter Geoghegan