Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
| От | Robert Haas |
|---|---|
| Тема | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
| Дата | |
| Msg-id | AANLkTikRX95K0bjf60xpO4ZMGikm7QrfRSNhKbTQuDw2@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid (Simon Riggs <simon@2ndQuadrant.com>) |
| Ответы |
Re: Re: new patch of MERGE (merge_204) & a question
about duplicated ctid
|
| Список | 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
В списке pgsql-hackers по дате отправления: