On Mon, Jan 3, 2011 at 8:35 AM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
