Re: Amcheck verification of GiST and GIN
От | Peter Geoghegan |
---|---|
Тема | Re: Amcheck verification of GiST and GIN |
Дата | |
Msg-id | CAH2-WzmfXgLLnAzB6cMZA74+fq8ud+ihieW5oFpYrxE2N8Vofw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Amcheck verification of GiST and GIN (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Amcheck verification of GiST and GIN
Re: Amcheck verification of GiST and GIN |
Список | pgsql-hackers |
On Thu, Feb 2, 2023 at 11:51 AM Peter Geoghegan <pg@bowt.ie> wrote: > I also have some questions about the verification functionality itself: I forgot to include another big concern here: * Why are there only WARNINGs, never ERRORs here? It's far more likely that you'll run into problems when running amcheck this way. I understand that the heapam checks can do that, but that is both more useful, and less risky. With heapam we're not traversing a tree structure in logical/keyspace order. I'm not claiming that this approach is impossible; just that it doesn't seem even remotely worth it. Indexes are never supposed to be corrupt, but if they are corrupt the solution always involves a REINDEX. You never try to recover the data from an index, since it's redundant and less authoritative, almost by definition (at least in Postgres). By far the most important piece of information is that an index has some non-zero amount of corruption. Any amount of corruption is supposed to be extremely surprising. It's kind of like if you see one cockroach in your home. The problem is not that you have one cockroach in your home; the problem is that you simply have cockroaches. We can all agree that in some abstract sense, fewer cockroaches is better. But that doesn't seem to have any practical relevance -- it's a purely theoretical point. It doesn't really affect what you do about the problem at that point. 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. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: