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

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Date: 2013-10-14 04:12:20
Message-ID: CAM3SWZQwph8FLS8iCBc0-SwFxDJ8E_5Jdh32_3Dasv+A-WbEYw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Oct 9, 2013 at 1:11 PM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> Unfortunately, I have a very busy schedule in the month ahead,
> including travelling to Ireland and Japan, so I don't think I'm going
> to get the opportunity to work on this too much. I'll try and produce
> a V4 that formally proposes some variant of my ideas around visibility
> of locked tuples.

V4 is attached.

Most notably, this adds the modifications to HeapTupleSatisfiesMVCC(),
though they're neater than in the snippet I sent earlier.

There is also some clean-up around row-level locking. That code has
been simplified. I also try and handle serialization failures in a
better way, though that really needs the attention of a subject matter
expert.

There are a few additional XXX comments highlighting areas of concern,
particularly around serializable behavior. I've deferred making higher
isolation levels care about wrongfully relying on the special
HeapTupleSatisfiesMVCC() exception (e.g. they won't throw a
serialization failure, mostly because I couldn't decide on where to do
the test on time prior to travelling tomorrow).

I've added code to do heap_prepare_insert before value locks are held.
Whatever our eventual value locking implementation, that's going to be
a useful optimization. Though unfortunately I ran out of time to give
this the scrutiny it really deserves, I suppose that it's something
that we can return to later.

I ask that reviewers continue to focus on concurrency issues and broad
design issues, and continue to defer discussion about an eventual
value locking implementation. I continue to think that that's the most
useful way of proceeding for the time being. My earlier points about
probable areas of concern [1] remain a good place for reviewers to
start.

[1] http://www.postgresql.org/message-id/CAM3SWZSvSrTzPhjNPjahtJ0rFfS-gJFhU86Vpewf+eO8GwZXNQ@mail.gmail.com

--
Peter Geoghegan

Attachment Content-Type Size
insert_on_dup.v4.2013_10_13.patch.gz application/x-gzip 36.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Soroosh Sardari 2013-10-14 06:21:55 Planner issue
Previous Message Andres Freund 2013-10-13 20:22:37 Re: Auto-tuning work_mem and maintenance_work_mem