Re: new heapcheck contrib module

> On Aug 28, 2020, at 11:10 AM, Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru> wrote:
>
>
>
>> 28 авг. 2020 г., в 18:58, Robert Haas <robertmhaas(at)gmail(dot)com> написал(а):
>> In the case
>> you mention, I think we should view that as a problem with clog rather
>> than a problem with the table, and thus out of scope.
>
> I don't think so. ISTM It's the same problem of xmax<relfrozenxid actually, just hidden behind detoasing.
> Our regular heap_check was checking xmin\xmax invariants for tables, but failed to recognise the problem in toast (while toast was accessible until CLOG truncation).
>
> Best regards, Andrey Borodin.

If you lock the relations involved, check the toast table first, the toast index second, and the main table third, do you still get the problem? Look at how pg_amcheck handles this and let me know if you still see a problem. There is the ever present problem that external forces, like a rogue process deleting backend files, will strike at precisely the wrong moment, but barring that kind of concurrent corruption, I think the toast table being checked prior to the main table being checked solves some of the issues you are worried about.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company