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
Ответ на
Список
Дерево обсуждения
gSoC add MERGE command new patch -- merge_v104 Boxuan Zhai <bxzhai2010@gmail.com>
Re: gSoC add MERGE command new patch -- merge_v104 Boxuan Zhai <bxzhai2010@gmail.com>
Re: gSoC add MERGE command new patch -- merge_v104 Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
Re: gSoC add MERGE command new patch -- merge_v104 Andres Freund <andres@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 Andres Freund <andres@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 Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>
Re: gSoC add MERGE command new patch -- merge_v104 Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>
Re: gSoC add MERGE command new patch -- merge_v104 Robert Haas <robertmhaas@gmail.com>
Re: gSoC add MERGE command new patch -- merge_v104 Boxuan Zhai <bxzhai2010@gmail.com>
Re: gSoC add MERGE command new patch -- merge_v104 David Fetter <david@fetter.org>
Re: gSoC add MERGE command new patch -- merge_v104 Simon Riggs <simon@2ndQuadrant.com>
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 по дате отправления
От: Simon Riggs
Дата:
Сообщение: Re: trace_recovery_messages
От: Heikki Linnakangas
Дата:
FAQ