> 19 авг. 2021 г., в 23:19, Mark Dilger <mark.dilger@enterprisedb.com> написал(а):
>
>
>
>> On Aug 19, 2021, at 10:57 AM, Peter Geoghegan <pg@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
matchingthose 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
currentstate 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
checkthat is symbiosis of "all indexed" check and heap check. Meanwhile, it's preferred that you can share heap scan
betweenmany 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
nearxmin\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
infoto all ERRCODE_DATA_CORRUPTED\ERRCODE_INDEX_CORRUPTED would suffice. Also, when monitoring wakes you at night you
wantto 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.