Horton

Re: Avoiding another needless ERROR during nbtree page deletion

Greg Stark <stark@mit.edu>

View thread View on postgr.es
From: Greg Stark <stark@mit.edu>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-06-01T10:47:40Z
Lists: pgsql-hackers 
On Mon, May 22, 2023, 12:31 Peter Geoghegan <pg@bowt.ie> wrote:

> On Sun, May 21, 2023 at 11:51 PM Heikki Linnakangas <hlinnaka@iki.fi>
> wrote:
> > Any idea what might cause this corruption?
>
> Not really, no. As far as I know the specific case that was brought to
> my attention (that put me on the path to writing this patch) was just
> an isolated incident. The interesting detail (if any) is that it was a
> relatively recent version of Postgres (13), and that there were no
> other known problems. This means that there is a plausible remaining
> gap in the defensive checks in nbtree VACUUM on recent versions -- we
> might have expected to avoid a hard ERROR in some other way, from one
> of the earlier checks, but that didn't happen on at least one
> occasion.
>

What error would one expect to see? I did have a case where vacuum was
erroring on a btree in $previous_job.

Commits

  1. nbtree VACUUM: cope with right sibling link corruption.

  2. Backpatch nbtree page deletion hardening.

  3. nbtree VACUUM: Cope with buggy opclasses.