Marko Tiikkaja wrote:
> What's been bothering me is that so far there has not been an
> agreement on whether we need to protect against concurrency issues or
> not. In fact, there has been almost no discussion about the
> concurrency issues which AIUI have been the biggest single reason we
> don't have MERGE already.
Sure there were, they just happened a long time ago. I tried to
summarize the previous discussion at
http://wiki.postgresql.org/wiki/SQL_MERGE with the following:
"PostgreSQL doesn't have a good way to lock access to a key value that
doesn't exist yet--what other databases call key range
locking...Improvements to the index implementation are needed to allow
this feature."
You can sift through the other archive links in there, the discussion
leading up to that conclusion is in there somewhere. And we had a
discussion of this at the last developer's meeting where this was
identified as a key issue to sort out before this was done; see the
table at the end of
http://wiki.postgresql.org/wiki/PgCon_2010_Developer_Meeting and note
the warning associated with this feature.
The deadlock on developing this feature has been that there's little
benefit to building key range locking on its own, or even a good way to
prove that it works, without a visible feature that uses it. It's much
easier to justify development time on if the rest of MERGE is known to
work, and just needs that plugged in to improve concurrency. And since
Boxuan appeared at the right time to do the syntax and implementation
part first as well, that's the order it's ended up happening in. We're
only making the concurrency part a second priority right now in order to
break the development into managable chunks.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
