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). -- 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