Re: Bug in amcheck?

On 02/11/2025 2:27 PM, Mihail Nikalayeu wrote:
> Hello!
>
>> I wonder if we should add P_ISHALFDEAD(opaque) for child page?
> I am not a btree expert, but things I was able to find so far:
>
> In commit d114cc538715e14d29d6de8b6ea1a1d5d3e0edb4 next check is added:
>
>> bt_child_highkey_check(state, downlinkoffnum,
>> child, topaque->btpo_level);
> At the same time there is a comment below:
>
>> * We go ahead with our checks if the child page is half-dead. It's safe
>> * to do so because we do not test the child's high key, so it does not
>> * matter that the original high key will have been replaced by a dummy
>> * truncated high key within _bt_mark_page_halfdead(). All other page
>> * items are left intact on a half-dead page, so there is still something
>> * to test.
> So, yes, it looks like we need to skip the child's high key test for
> half-dead pages.
>
> BWT, have you tried to create an injection_point-based reproducer?
>
> Best regards,
> Mikhail.

Hello Mikhail,

Thank you very much for looking at this issue. And I am very sorry for
delay with answer.
Unfortunately I was not able to reproduce the problem for the latest
Postgres: neither with injection points, neither with my original
approach with sleeps.

Originally I investigated the customer's problem with PG16. And have
reproduced it for pg16,. I checked that relevant amcheck code was not
changed since pg16, so I thought that the problem takes place for all
Postgres versions. But looks like it is not true.