| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(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:58:44 |
| Message-ID: | 4D21F234.9030707@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2011-01-03 15:59:54 | Re: Streaming replication as a separate permissions |
| Previous Message | Stephen Frost | 2011-01-03 15:56:27 | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |