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. In serializable mode you get a serialization
error.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
