On Sun, Dec 28, 2014 at 3:19 PM, Peter Geoghegan <pg@heroku.com> wrote:
On Fri, Dec 26, 2014 at 4:22 PM, Peter Geoghegan <pg@heroku.com> wrote: > So looking at the way the system deals with its dependence on default > operator classes, I have a hard time justifying all this extra > overhead for the common case.
Attached pair of revised patch sets, V1.8:
Hi Peter,
Using the vallock2 version of V1.8, using the test I previously described, I get some all-null rows, which my code should never create. Also, the index and table don't agree, in this example I find 3 all-null rows in the table, but only 2 in the index. I've attached an example output of querying via index and via full table scan, and also the pageinspect output of the blocks which have the 3 rows, in case that is helpful.
This was just a straight forward issue of firing queries at the database, the crash-inducing part of my test harness was not active during this test. I also ran it with my crashing patch reversed out, in case I introduced the problem myself, and it still occurs.
Using V1.7 of the vallock2 patch, I saw the same thing with some all-null rows. I also saw some other issues where two rows with the same key value would be present twice in the table (violating the unique constraint) but only one of them would appear in the index. I suspect it is caused by the same issue as the all-null rows, and maybe I just didn't run v1.8 enough times to find that particular manifestation under v1.8.
