| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Boxuan Zhai <bxzhai2010(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
| Date: | 2011-01-03 13:35:53 |
| Message-ID: | 1294061753.19612.748.camel@ebony |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Simon Riggs http://www.2ndQuadrant.com/books/
PostgreSQL Development, 24x7 Support, Training and Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2011-01-03 14:38:56 | Re: [PATCH] V3: Idle in transaction cancellation |
| Previous Message | Heikki Linnakangas | 2011-01-03 13:12:10 | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |