From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(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:08:51 |
Message-ID: | 4D21F493.2050304@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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. In serializable mode you get a serialization
error.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-01-03 16:14:26 | Re: Scanning pg_tablespace from walsender |
Previous Message | Andrew Dunstan | 2011-01-03 16:06:15 | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |