Re: Amcheck verification of GiST and GIN

Поиск
Список
Период
Сортировка
От Nikolay Samokhvalov
Тема Re: Amcheck verification of GiST and GIN
Дата
Msg-id CANNMO+JjEMfb1VBg8xNt-QMiZ-Nf+w+WGNm9of7UYFgM4P08tA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Amcheck verification of GiST and GIN  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: Amcheck verification of GiST and GIN  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-hackers
On Thu, Feb 2, 2023 at 12:15 PM Peter Geoghegan <pg@bowt.ie> wrote:
On Thu, Feb 2, 2023 at 11:51 AM Peter Geoghegan <pg@bowt.ie> wrote:
... 
Admittedly there is some value in seeing multiple WARNINGs to true
experts that are performing some kind of forensic analysis, but that
doesn't seem worth it to me -- I'm an expert, and I don't think that
I'd do it this way for any reason other than it being more convenient
as a way to get information about a system that I don't have access
to. Even then, I think that I'd probably have serious doubts about
most of the extra information that I'd get, since it might very well
be a downstream consequence of the same basic problem.
...

I understand your thoughts (I think) and agree with them, but at least one
scenario where I do want to see *all* errors is corruption prevention – running
amcheck in lower environments, not in production, to predict and prevent issues.
For example, not long ago, Ubuntu 16.04 became EOL (in phases), and people
needed to upgrade, with glibc version change. It was quite good to use amcheck
on production clones (running on a new OS/glibc) to identify all indexes that
need to be rebuilt. Being able to see only one of them would be very
inconvenient. Rebuilding all indexes didn't seem a good idea in the case of
large databases.

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

Предыдущее
От: Corey Huinker
Дата:
Сообщение: Re: transition tables and UPDATE
Следующее
От: Jim Jones
Дата:
Сообщение: [PATCH] Add pretty-printed XML output option