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.
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 |