Message-ID: <71fbc31f-51c1-92cc-594e-834dd4c4fcd9@gmail.com>
Date: Tue, 6 Jun 2023 06:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #17959: amcheck fails to find a matching index tuple for an
 invisible heap tuple
Content-Language: en-US
To: Peter Geoghegan <pg@bowt.ie>
Cc: pgsql-bugs@lists.postgresql.org
References: <17959-0d691c29037366ab@postgresql.org>
 <bc2bd0cc-4a19-b311-043f-f9a40e71dfe8@gmail.com>
 <CAH2-WzngU5tZKG3XpG4jtyi_mwX75YVQn3GOWsEK3W45kAFY6g@mail.gmail.com>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: 
 <CAH2-WzngU5tZKG3XpG4jtyi_mwX75YVQn3GOWsEK3W45kAFY6g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/71fbc31f-51c1-92cc-594e-834dd4c4fcd9%40gmail.com>
Precedence: bulk

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