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. Regards, Hari Babu Fujitsu Australia
