> On Aug 28, 2020, at 11:10 AM, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>
>
>
>> 28 авг. 2020 г., в 18:58, Robert Haas <robertmhaas@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
(whiletoast 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
youstill get the problem? Look at how pg_amcheck handles this and let me know if you still see a problem. There is
theever present problem that external forces, like a rogue process deleting backend files, will strike at precisely the
wrongmoment, but barring that kind of concurrent corruption, I think the toast table being checked prior to the main
tablebeing checked solves some of the issues you are worried about.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company