On Mon, Jan 3, 2011 at 11:08 AM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > On 03.01.2011 18:02, Robert Haas wrote: >> >> On Mon, Jan 3, 2011 at 10:58 AM, Heikki Linnakangas >> <heikki.linnakan...@enterprisedb.com> wrote: >>> >>> On 03.01.2011 17:56, Stephen Frost wrote: >>>> >>>> * Robert Haas (robertmh...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers