Re: Concurrent MERGE - Mailing list pgsql-hackers

From Chris Browne
Subject Re: Concurrent MERGE
Date
Msg-id 874of93rz5.fsf@cbbrowne.afilias-int.info
Whole thread Raw
In response to Concurrent MERGE  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Concurrent MERGE
List pgsql-hackers
robertmhaas@gmail.com (Robert Haas) writes:
> On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> Looks like MERGE is progressing well.
>>
>> At 2010 Dev Mtg, we put me down to work on making merge work
>> concurrently. That was garbled slightly and had me down as working on
>> predicate locking which is the general solution to the problem.
>>
>> Do we still need me to work on concurrent MERGE, or is that included in
>> the current MERGE patch (can't see it), or is that covered elsewhere
>> (for example Kevin Grittner's recent work)?
>>
>> Still happy to do work as proposed, just checking still required.
>
> I suspect Kevin's patch will solve it if using a sufficiently high
> transaction isolation level, but something else might be needed
> otherwise.  However, I confess to ignorance as to the underlying
> issues?  Why is MERGE worse in this regard than, say, UPDATE?

It's worse than UPDATE because- It could be an INSERT, if the data's new, but- If the data's there, it becomes an
UPDATE,but- If some concurrent update has just DELETEd the data that's there, it  becomes an INSERT again, but- Oops,
thatDELETE rolled bac, so it's an UPDATE again...
 

Recurse as needed to make it more undecidable as to whether it's really
an INSERT or an UPDATE :-).
-- 
Rules of the Evil Overlord #208.  "Members of my Legion of Terror will
attend seminars  on Sensitivity  Training. It's good  public relations
for them to  be kind and courteous to the  general population when not
actively engaged in sowing chaos and destruction."


pgsql-hackers by date:

Previous
From: pgsql-hackers@news.hub.org
Date:
Subject: pgsql-hackers@news.hub.org 37% OFF on Pfizer!
Next
From: Chris Browne
Date:
Subject: Re: Two different methods of sneaking non-immutable data into an index