On Mon, Jan 3, 2011 at 11:08 AM, Heikki Linnakangas
> 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.
The Enterprise PostgreSQL Company
In response to
pgsql-hackers by date
|Next:||From: Robert Haas||Date: 2011-01-03 16:23:29|
|Subject: Re: Streaming replication as a separate permissions|
|Previous:||From: Tom Lane||Date: 2011-01-03 16:20:38|
|Subject: Re: Streaming replication as a separate permissions |