> 19 авг. 2021 г., в 23:19, Mark Dilger <mark.dil...@enterprisedb.com>
> написал(а):
>
>
>
>> On Aug 19, 2021, at 10:57 AM, Peter Geoghegan <p...@bowt.ie> wrote:
>>
>> High
>> verbosity makes a lot of sense here.
>
> Works for me. We could create another function, "verify_heapam_full"
> perhaps, that returns additional columns matching those from pageinspect's
> heap_page_items():
Currently I'm mostly interested in index functions to investigate CIC bug.
I see 4 different cases for corruption checks:
1. Developer tackling a bug
2. Backup smoke test
3. DBA recovering corrupted data
4. Running system detects anomaly
In case 1 you want to find corruption and trace back events that lead to it.
You need all the bits that can connect current state with events in the past.
In case 2 you want succinct check, that in case of fire provides initial
information for case 3. Ideally you want a check that is symbiosis of "all
indexed" check and heap check. Meanwhile, it's preferred that you can share
heap scan between many index checks.
In case 3 you want to collect all corrupted data (find everything with same
xmin\xmax, or on the same page, or with near xmin\xmax). In this case returning
heap page right away would be quite useful.
Sometimes you want to create backup copy of the page to try some surgery.
(create table backup_pages as select from verify_heapam_full())
In case 4 you want to alarm DBA and provide all the necessary information to
start 3. Adding standardised corruption info to all
ERRCODE_DATA_CORRUPTED\ERRCODE_INDEX_CORRUPTED would suffice. Also, when
monitoring wakes you at night you want to know:
- How many tuples are corrupted?
- How long ago data was corrupted? Is corrupted data within PITR window yet?
- Where to seek a manual for recovery?
But I don't think we can have this logged in case of "ERROR: t_xmin is
uncommitted in tuple to be updated"
Thanks!
Best regards, Andrey Borodin.
