From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Boxuan Zhai <bxzhai2010(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: gSoC add MERGE command new patch -- merge_v104 |
Date: | 2010-08-25 09:41:24 |
Message-ID: | 20100825094124.GA2902@anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Aug 25, 2010 at 09:26:51AM +0300, Heikki Linnakangas wrote:
> On 24/08/10 23:56, Andres Freund wrote:
> >I have to ask one question: On a short review of the discussion and
> >the patch I didn't find anything about the concurrency issues
> >involved (at least nodeModifyTable.c didnt show any).
> The SQL spec doesn't require MERGE to be an atomic "upsert" operation.
> >Whats the plan to go forward at that subject? I think the patch needs
> >to lock tables exclusively (the pg level, not access exclusive) as
> >long as there is no additional handling...
> Well, you can always do LOCK TABLE before calling MERGE if that's
> what you want, but I don't think doing that automatically would make
> people happy.
But randomly loosing tuples will make much more people unhappy. At a
much more problematic point of time (in production).
There is no locking prohibiting situations like trying to update a
tuple which was concurrently deleted and thus loosing a tuple. Unless
I miss something.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2010-08-25 09:44:24 | Re: gSoC add MERGE command new patch -- merge_v104 |
Previous Message | Simon Riggs | 2010-08-25 09:36:00 | Re: trace_recovery_messages |