Re: new heapcheck contrib module
От | Peter Geoghegan |
---|---|
Тема | Re: new heapcheck contrib module |
Дата | |
Msg-id | CAH2-WzmNiq2OSVmMcmeP8-bpNJhtHWe91ZjsGqOJ+VumifsXrw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: new heapcheck contrib module (Mark Dilger <mark.dilger@enterprisedb.com>) |
Список | pgsql-hackers |
On Sat, Aug 29, 2020 at 10:48 AM Mark Dilger <mark.dilger@enterprisedb.com> wrote: > I had an earlier version of the verify_heapam patch that included a non-throwing interface to clog. Ultimately, I rippedthat out. My reasoning was that a simpler patch submission was more likely to be acceptable to the community. Isn't some kind of pragmatic compromise possible? > But I don't want to make this patch dependent on that hypothetical patch getting written and accepted. Fair enough, but if you're alluding to what I said then about check_tuphdr_xids()/clog checking a while back then FWIW I didn't intend to block progress on clog/xact status verification at all. I just don't think that it is sensible to impose an iron clad guarantee about having no assertion failures with corrupt clog data -- that leads to far too much code duplication. But why should you need to provide an absolute guarantee of that? I for one would be fine with making the clog checks an optional extra, that rescinds the no crash guarantee that you're keen on -- just like with the TOAST checks that you have already in v15. It might make sense to review how often crashes occur with simulated corruption, and then to minimize the number of occurrences in the real world. Maybe we could tolerate a usually-no-crash interface to clog -- if it could still have assertion failures. Making a strong guarantee about assertions seems unnecessary. I don't see how verify_heapam will avoid raising an error during basic validation from PageIsVerified(), which will violate the guarantee about not throwing errors. I don't see that as a problem myself, but presumably you will. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: