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:21:15
Message-ID: AANLkTinh5CHjuxUcAjbMeXt5AGrkOxZ==ADUcHDnxeui@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Mon, Jan 3, 2011 at 11:08 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 03.01.2011 18:02, Robert Haas wrote:
>>
>> 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).
>
> It works in read committed mode, because you acquire a new snapshot after
> the LOCK TABLE, and anyone else who modified the table must commit before
> the lock is granted.

Oh, I forgot we hold the ROW EXCLUSIVE lock until commit.  That might
be OK, then.

> In serializable mode you get a serialization error.

I don't think this part is true.  You can certainly do this:

CREATE TABLE test (a int);
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SELECT * FROM test;
<in another session, insert (1) into test>
LOCK TABLE test IN SHARE MODE; -- or just LOCK TABLE test, if you prefer
SELECT * FROM test;  -- still ain't there
INSERT INTO test VALUES (1);

I don't see what would make MERGE immune to this.

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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-01-03 16:23:29
Subject: Re: Streaming replication as a separate permissions
Previous:From: Tom LaneDate: 2011-01-03 16:20:38
Subject: Re: Streaming replication as a separate permissions

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