Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Simon Riggs <simon@2ndquadrant.com>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Greg Smith <greg@2ndquadrant.com>, Marko Tiikkaja <marko.tiikkaja@cs.helsinki.fi>, Boxuan Zhai <bxzhai2010@gmail.com>, pgsql-hackers@postgresql.org
Date: 2011-01-03T14:57:27Z
Lists: pgsql-hackers
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