Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

On Sun, Dec 28, 2014 at 3:19 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:

> On Fri, Dec 26, 2014 at 4:22 PM, Peter Geoghegan <pg(at)heroku(dot)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.

Cheers,

Jeff