Re: gSoC add MERGE command new patch -- merge_v104
От | Andres Freund |
---|---|
Тема | Re: gSoC add MERGE command new patch -- merge_v104 |
Дата | |
Msg-id | 20100825094124.GA2902@anarazel.de обсуждение исходный текст |
Ответ на | Re: gSoC add MERGE command new patch -- merge_v104 (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: gSoC add MERGE command new patch -- merge_v104
|
Список | 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
В списке pgsql-hackers по дате отправления: