Re: Amcheck: do rightlink verification with lock coupling - Mailing list pgsql-hackers

From Andrey M. Borodin
Subject Re: Amcheck: do rightlink verification with lock coupling
Date
Msg-id 230495AF-54F2-4DDC-9C94-F6BF9BE79C65@yandex-team.ru
Whole thread Raw
In response to Re: Amcheck: do rightlink verification with lock coupling  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Amcheck: do rightlink verification with lock coupling  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers

> 6 авг. 2020 г., в 21:38, Peter Geoghegan <pg@bowt.ie> написал(а):
>
> On Wed, Aug 5, 2020 at 9:50 PM Andrey M. Borodin <x4mmm@yandex-team.ru> wrote:
>> Sounds great! Thanks!
>
> I'm afraid that there is another problem, this time with
> btree_xlog_split(). It's possible to get false positives when running
> the new test continually on a standby. You can see this by running
> verification on a standby continually, while the primary runs with a
> workload that gets many page splits.
Yes, I see the problem...
>
> The only thing that we can do is adjust the locking in
> btree_xlog_split() to match the primary (kind of like commit 9a9db08a,
> except with page splits instead of page deletion). Attached is a
> revised version of the patch, along with the changes that we'd need to
> REDO to make the amcheck patch really work.
>
> I'm not sure if this change to the REDO routine is worth the overhead
> or trouble, though. I have to think about it some more.
If we want to check relations between pages we must either apply them together (under locks) or tolerate some fraction
offalse positives. I understand that mitigating and tolerating false positives is nonsense in mathematica sense, but
frompractical point of view it's just OK. 

But having complete solution with no false positives seems much better.

>
> BTW, the first patch in the series now has a new check for page
> deletion -- that was missing from v4.
Yes, seems like that was a bug..

Thanks!

Best regards, Andrey Borodin.




pgsql-hackers by date:

Previous
From: Etsuro Fujita
Date:
Subject: Re: Yet another issue with step generation in partition pruning
Next
From: Asim Praveen
Date:
Subject: Re: [PATCH] - Provide robust alternatives for replace_string