Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

On Thu, Dec 12, 2013 at 1:47 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Sorry, I dropped the ball on this.

Thank you for your patience, Heikki.

I attached two revisions - one of my patch (btreelock_insert_on_dup)
and one of your alternative design (exclusion_insert_on_dup). In both
cases I've added a new visibility rule to HeapTupleSatisfiesUpdate(),
and enabled projecting on duplicate-causing-tid by means of the ctid
system column when RETURNING REJECTS. I'm not in an immediate position
to satisfy myself that the former revision is correct (I'm travelling
tomorrow morning and running a bit short on time) and I'm not
proposing the latter for inclusion as part of the feature (that's a
discussion we may have in time, but it serves a useful purpose during
testing).

Both of these revisions have identical ad-hoc test cases included as
new files - see testcase.sh and upsert.sql. My patch doesn't have any
unique constraint violations, and has pretty consistent performance,
while yours has many unique constraint violations. I'd like to hear
your thoughts on the testcase, and the design implications.

--
Peter Geoghegan