On 05/08/10 18:57, Robert Haas wrote:
> 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.
With truly serializable isolation I think you'll get a serialization
failure error.
> However, I confess to ignorance as to the underlying
> issues? Why is MERGE worse in this regard than, say, UPDATE?
MERGE can be used to implement "upsert", where a row is updated if it
exists and inserted if it doesn't. I don't think Kevin's patch will
suffice for that. You don't usually want a serialization failure error
when you run two upserts at the same time, you want both of them to
succeed, one doing an insert and the other one doing an update.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com