Re: Avoiding another needless ERROR during nbtree page deletion

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: Avoiding another needless ERROR during nbtree page deletion
Дата
Msg-id CAM-w4HNc1ikz=R7O4c_UqsycqffXm8rZLfJXLyu+JswX-9u4nQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Avoiding another needless ERROR during nbtree page deletion  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Avoiding another needless ERROR during nbtree page deletion
Список 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. 

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Shinoda, Noriyoshi (PN Japan FSIP)"
Дата:
Сообщение: RE: [16Beta1][doc] pgstat: Track time of the last scan of a relation
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Do we want a hashset type?