Hello Peter,
Thanks for looking into this!
05.06.2023 19:27, Peter Geoghegan wrote:
> On Mon, Jun 5, 2023 at 2:00 AM Alexander Lakhin <exclusion@gmail.com> wrote:
>> A complete TAP test to reproduce the issue is attached.
>> I put it in src/bin/pg_amcheck/t/, run (on master, e6a254c0d)
>> PROVE_TESTS=t/099_pdri_error.pl make -s check -C src/bin/pg_amcheck/
>> and get:
>>
>> # Failed test 'pg_amcheck after manipulations stdout /(?^:^$)/'
>> # at t/099_pdri_error.pl line 60.
>> # 'btree index "regress001.pg_catalog.pg_depend_reference_index":
>> # ERROR: heap tuple (13,35) from table "pg_depend" lacks matching index tuple within index
"pg_depend_reference_index"
>> # '
>> # doesn't match '(?^:^$)'
> I can easily reproduce this result using your test case.
>
> I notice that the test case will pass if I remove your use of the
> "--rootdescend" option from your tap test script. This suggests that
> the problem is somehow limited to heapallindexed verification when run
> through the bt_index_parent_check() interface -- bt_index_check()
> heapallindexed verification seems unaffected. The former works rather
> like a CREATE INDEX internally (and so can just use SnapshotAny),
> while the latter works more like CREATE INDEX CONCURRENTLY (and so
> must use an MVCC snapshot).
Yes, I can confirm that bt_index_parent_check() calls
bt_check_every_level(... readonly = true ...) and in this case snapshot = SnapshotAny
is used.
SELECT * FROM bt_index_parent_check('pg_catalog.pg_depend_reference_index'::regclass, true, false)
gives the same error (and it looks like the parameter rootdescend of
bt_index_parent_check() doesn't affect this).
BTW, with the DEBUG2 log level I get a message:
verifying that tuples from index "pg_depend_reference_index" are present in "pg_depend"
but doesn't the verification work the other way?
Best regards,
Alexander
