Re: amcheck (B-Tree integrity checking tool)

On Wed, Nov 30, 2016 at 9:06 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:

> On Wed, Nov 23, 2016 at 2:47 PM, Thomas Munro
> <thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> > Actually I meant that at T2 the btree is exactly same as it was at T1,
> > but the order of the values has changed according to the comparator
> > (for example, because a collation definition changed when you updated
> > your operating system), so that the btree is now corrupted. Based on
> > Goetz Graefe's paper I was wondering if amcheck would be unable to
> > detect this due to the cousin problem.
>
> I love that paper (it's more like a book, really). I'm glad that at
> least one other person in the community has read some of it, because I
> think it has a lot of clues as to how we can begin to address some of
> our problems around bloat without novel redesign. Most of the
> techniques are quite complementary.
>
> I wrote a prototype of suffix truncation for text in two days last
> week. The regression tests pass, and the technique works well for
> certain cases, particularly with many column indexes without
> correlation (the index-only-scan case). Let's see if that becomes a
> real patch.
>
> > Thank you for your patient explanation!
>
> Your questions were excellent, and so deserved my careful consideration.
>
> > Please see my humble attempt
> > to test this scenario and learn something about btrees in the process,
> > attached. amcheck does detect the violation of the high key
> > invariant.
>
> This is a nice pattern for testing out if the keyspace is sane, and
> how things work. I might incorporate it into my own testing in the
> future.

Moved to next CF with " needs review" status.

Regards,
Hari Babu
Fujitsu Australia