Re: Avoiding another needless ERROR during nbtree page deletion

From: Greg Stark <stark(at)mit(dot)edu>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Avoiding another needless ERROR during nbtree page deletion
Date: 2023-06-01 10:47:40
Message-ID: CAM-w4HNc1ikz=R7O4c_UqsycqffXm8rZLfJXLyu+JswX-9u4nQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, May 22, 2023, 12:31 Peter Geoghegan <pg(at)bowt(dot)ie> wrote:

> On Sun, May 21, 2023 at 11:51 PM Heikki Linnakangas <hlinnaka(at)iki(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2023-06-01 10:51:21 Re: Do we want a hashset type?
Previous Message Shinoda, Noriyoshi (PN Japan FSIP) 2023-06-01 09:38:18 RE: [16Beta1][doc] pgstat: Track time of the last scan of a relation