Re: amcheck (B-Tree integrity checking tool) - Mailing list pgsql-hackers

From Matt Kelly
Subject Re: amcheck (B-Tree integrity checking tool)
Date
Msg-id CA+KcUkjuo=vwabJ54tcHHdZLbN2gK-w45AVNOsvN0FSjEsSKCA@mail.gmail.com
Whole thread Raw
In response to Re: amcheck (B-Tree integrity checking tool)  (Peter Geoghegan <pg@heroku.com>)
Responses Re: amcheck (B-Tree integrity checking tool)
List pgsql-hackers
On Fri, 2016-03-11 at 17:24 +0100, Michael Paquier wrote:
> On Fri, Mar 11, 2016 at 5:19 PM, Anastasia Lubennikova wrote:
> >
> > BTW, if you know a good way to corrupt index (and do it
> > reproducible) I'd be
> > very glad to see it.
> You can use for example dd in non-truncate mode to corrupt on-disk
> page data, say that for example:
> dd if=/dev/random bs=8192 count=1 \
>     seek=$BLOCK_ID of=base/$DBOID/$RELFILENODE \
>     conv=notrunc
I guess /dev/random is not very compatible with the "reproducible"
requirement. I mean, it will reproducibly break the page, but pretty
much completely, which is mostly what checksums are for.

You can actually pretty easily produce a test case by setting up streaming replication between servers running two different version of glibc.

I actually wrote a tool that spins up a pair of VMs using vagrant and then sets them up as streaming replica's using ansible.  It provides a nice one liner to get a streaming replica test environment going and it will easily provide the cross glibc test case.  Technically, though it belongs to Trip because I wrote it on company time.  Let me see if I can open source a version of it later this week that way you can use it for testing.

- Matt K.

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: MinGW versus _strtoui64() ?
Next
From: Amit Kapila
Date:
Subject: Re: Explain [Analyze] produces parallel scan for select Into table statements.