Re: Do not check unlogged indexes on standby

> 13 авг. 2019 г., в 3:23, Peter Geoghegan <pg@bowt.ie> написал(а):
>
> I pushed your patch to all branches that have amcheck just now, so now
> we skip over unlogged relations when in recovery, though I made some
> revisions.
Oh, cool, thanks!

> Your patch didn't handle temp tables/indexes that were created in the
> first session correctly -- we must be careful about the distinction
> between unlogged tables, and tables that don't require WAL logging
> (the later includes temp tables). Also, I thought that it was a good
> idea to actively test for the presence of a main fork when we don't
> skip (i.e. when the system isn't in recovery and the B-Tree indexes
> isn't unlogged) -- we now give a clean report of corruption when that
> happens, rather than letting an ambiguous "can't happen" error get
> raised by low-level code. This might be possible with system catalog
> corruption, for example. Finally, I thought that the WARNING was a bit
> strong -- a NOTICE is more appropriate.
+1

> 13 авг. 2019 г., в 3:36, Peter Geoghegan <pg@bowt.ie> написал(а):
>
> On Mon, Aug 12, 2019 at 2:58 AM Andrey Borodin <x4mmm@yandex-team.ru> wrote:
>> BTW I really want to enable rightlink-leftlink invariant validation on standby..
>
> That seems very hard. My hope was that bt_check_index() can detect the
> same problem a different way. The bt_right_page_check_scankey()
> cross-page check (which needs nothing more than an AccessShareLock)
> will often detect such problems, because the page image itself will be
> totally wrong in some way.
>
> I'm guessing that you have direct experience with that *not* being
> good enough, though. Can you share further details? I suppose that
> bt_right_page_check_scankey() helps with transposed pages, but doesn't
> help so much when you have WAL-level inconsistencies.

We have a bunch of internal testing HA clusters that suffered from corruption conditions.
We fixed everything that can be detected with parent-check on primaries or usual check on standbys.
(page updates were lost both on primary and during WAL replay)
But from time to time when clusters switch primary from one availability zone to another we observe
"right sibling's left-link doesn't match: block 32709 links to 37022 instead of expected 40953 in index"

We are going to search for these clusters with this [0] tolerating possible fraction of false positives, we have them
anyway.
But I think I could put some effort into making corruption-detection tooling better.
I think if we observe links discrepancy, we can acquire lock of left and right pages and recheck.


Best regards, Andrey Borodin.

[0] https://github.com/x4m/amcheck/commit/894d8bafb3c9a26bbc168ea5f4f33bcd1fc9f495