On Wed, Nov 30, 2016 at 9:06 AM, Peter Geoghegan <pg@heroku.com> wrote:
On Wed, Nov 23, 2016 at 2:47 PM, Thomas Munro <thomas.munro@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.