Re: Concurrent MERGE

From: Chris Browne <cbbrowne(at)acm(dot)org>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Concurrent MERGE
Date: 2010-08-05 17:10:54
Message-ID: 874of93rz5.fsf@cbbrowne.afilias-int.info
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

robertmhaas(at)gmail(dot)com (Robert Haas) writes:
> On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs <simon(at)2ndquadrant(dot)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, that DELETE 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."

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-08-05 17:19:41 Re: BUG #5599: Vacuum fails due to index corruption issues
Previous Message Chris Browne 2010-08-05 16:59:06 Re: Two different methods of sneaking non-immutable data into an index