On Mon, Jan 3, 2011 at 10:58 AM, Heikki Linnakangas
> 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
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2011-01-03 16:06:15|
|Subject: Re: Re: new patch of MERGE (merge_204) & a question about
|Previous:||From: Robert Haas||Date: 2011-01-03 15:59:54|
|Subject: Re: Streaming replication as a separate permissions|