Skip site navigation (1) Skip section navigation (2)

Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

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 (view raw or flat)
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
 


In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2011-01-03 14:38:56
Subject: Re: [PATCH] V3: Idle in transaction cancellation
Previous:From: Heikki LinnakangasDate: 2011-01-03 13:12:10
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group