On Wed, Nov 30, 2016 at 9:06 AM, Peter Geoghegan <p...@heroku.com> wrote:

> On Wed, Nov 23, 2016 at 2:47 PM, Thomas Munro
> <thomas.mu...@enterprisedb.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.

Hari Babu
Fujitsu Australia

Reply via email to