On 05/08/10 18:57, Robert Haas wrote:
On Thu, Aug 5, 2010 at 11:43 AM, Simon Riggs<si...@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.
With truly serializable isolation I think you'll get a serialization
failure error.
However, I confess to ignorance as to the underlying
issues? Why is MERGE worse in this regard than, say, UPDATE?
MERGE can be used to implement "upsert", where a row is updated if it
exists and inserted if it doesn't. I don't think Kevin's patch will
suffice for that. You don't usually want a serialization failure error
when you run two upserts at the same time, you want both of them to
succeed, one doing an insert and the other one doing an update.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
