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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Simon Riggs <simon(at)2ndquadrant(dot)com>, 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 16:02:26
Message-ID: AANLkTi=P_PVOk+_Yp5oG8Ue6q4ZXQmsEiSd_jBHx7EVn@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jan 3, 2011 at 10:58 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 03.01.2011 17:56, Stephen Frost wrote:
>>
>> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>>>
>>> Like Heikki, I'd rather have the feature without a workaround for the
>>> concurrency issues than no feature.
>>
>> I'm still trying to figure out the problem with having the table-level
>> lock, unless we really think people will be doing concurrent MERGE's
>> where they won't overlap..?  I'm also a bit nervous about if the result
>> of concurrent MERGE's would actually be correct if we're not taking a
>> bigger lock than row-level (I assume we're taking row-level locks as it
>> goes through..).
>>
>> In general, I also thought/expected to have some kind of UPSERT type
>> capability with our initial MERGE support, even if it requires a big
>> lock and won't operate concurrently, etc.
>
> You can of course LOCK TABLE as a work-around, if that's what you want.

That work-around completely fails to solve the concurrency problem.
Just because you have a lock on the table doesn't mean that there
aren't already tuples in the table which are invisible to your
snapshot (for example because the inserting transactions haven't
committed yet).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-01-03 16:06:15
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Previous:From: Robert HaasDate: 2011-01-03 15:59:54
Subject: Re: Streaming replication as a separate permissions

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