Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0

On Thu, Apr 23, 2015 at 1:08 PM, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
> That said, I'd actually like to see a separate heap_super_delete() function
> for that, rather than piggybacking on heap_delete(). It's a quite different
> operation. There'll be some duplication, but seems better than a maze of
> if-else's in heap_delete.

I found a bug that seems to be down to commit
e3144183562d08e347f832f0b29daefe8bac617b on Github:

"""
commit e3144183562d08e347f832f0b29daefe8bac617b
Author: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
Date: Thu Apr 23 18:38:11 2015 +0300

Minor cleanup of check_exclusion_or_unique_constraint.

To improve readability.

"""

At least, that's what a "git bisect" session showed.

Basically, at high client counts (128 clients only), after a few
iterations of the B-Tree test, the latest version of jjanes_upsert
would see this happen (error originates fromExecOnConflictUpdate(),
with custom instrumentation added to identify invisible tuple):

2015-04-23 15:10:48 PDT [ txid: 0 ]: LOG: database system was shut
down at 2015-04-23 15:10:09 PDT
2015-04-23 15:10:48 PDT [ txid: 0 ]: LOG: database system is ready
to accept connections
2015-04-23 15:12:55 PDT [ txid: 472418 ]: ERROR: attempted to lock
invisible tuple (140,39)
2015-04-23 15:12:55 PDT [ txid: 472418 ]: STATEMENT: insert into
upsert_race_test (index, filler, count) values ('3896',
random_characters(), '1') on conflict (index)
update set count=TARGET.count + EXCLUDED.count, filler =
EXCLUDED.filler
where TARGET.index = EXCLUDED.index
returning count

This seemed to only show up when fsync = on on my laptop, whereas in
the past some race conditions that I've found were easier to recreate
with fsync = off.

I attach some notes from my bisect/debugging session, including
pg_xlogdump output (from a psql session - I like to manipulate
pg_xlogdump output using SQL). That's probably not all that
interesting, but I attach it all the same. Hopefully this is something
that Heikki can easily debug, since the commit implicated here only
concerned readability. A simple oversight? If you want, Heikki, I can
try and debug it, but it seems like something we're better off having
you sign off on if possible.

Thanks
--
Peter Geoghegan