On Mon, Jan 3, 2011 at 8:35 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> On Mon, 2011-01-03 at 15:12 +0200, Heikki Linnakangas wrote:
>> This patch has never tried to implement concurrency-safe upsert. It
>> implements the MERGE command as specified by the SQL standard, nothing
>> more, nothing less. Let's not move the goalposts. Googling around, at
>> least MS SQL Server's MERGE command is the same
>> (http://weblogs.sqlteam.com/dang/archive/2009/01/31/UPSERT-Race-Condition-With-MERGE.aspx).
>> There is nothing embarrassing about it, we just have to document it clearly.
>
> That article says that SQLServer supplies a locking hint that completely
> removes the issue. Because they use locking, they are able to update in
> place, so there is no need for them to use snapshots.
>
> Our version won't allow a workaround yet, just for the record.
Like Heikki, I'd rather have the feature without a workaround for the
concurrency issues than no feature. But I have to admit that the
discussion we've had thus far gives me very little confidence that
this code is anywhere close to bug-free. So I think we're going to
end up punting it to 9.2 not so much because it's not concurrency-safe
as because it doesn't work.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
