From: | Stephen Frost <sfrost(at)snowman(dot)net> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(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 15:56:27 |
Message-ID: | 20110103155627.GI4933@tamriel.snowman.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
* 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.
> But I have to admit that the
> discussion we've had thus far gives me very little confidence that
> this code is anywhere close to bug-free. So I think we're going to
> end up punting it to 9.2 not so much because it's not concurrency-safe
> as because it doesn't work.
That's certainly a concern. :/
Stephen
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2011-01-03 15:58:44 | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
Previous Message | Robert Haas | 2011-01-03 15:52:20 | Re: Scanning pg_tablespace from walsender |