Re: Concurrent MERGE

Поиск
Список
Период
Сортировка
От Chris Browne
Тема Re: Concurrent MERGE
Дата
Msg-id 874of93rz5.fsf@cbbrowne.afilias-int.info
обсуждение исходный текст
Ответ на Concurrent MERGE  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Concurrent MERGE  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список 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 по дате отправления:

Предыдущее
От: pgsql-hackers@news.hub.org
Дата:
Сообщение: pgsql-hackers@news.hub.org 37% OFF on Pfizer!
Следующее
От: Chris Browne
Дата:
Сообщение: Re: Two different methods of sneaking non-immutable data into an index