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."
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 |