> On Aug 28, 2020, at 11:10 AM, Andrey M. Borodin <x4...@yandex-team.ru> wrote:
>
>
>
>> 28 авг. 2020 г., в 18:58, Robert Haas <robertmh...@gmail.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
