Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
От | Heikki Linnakangas |
---|---|
Тема | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
Дата | |
Msg-id | 4D21F234.9030707@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Re: new patch of MERGE (merge_204) & a question about
duplicated ctid
Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
Список | pgsql-hackers |
On 03.01.2011 17:56, Stephen Frost wrote: > * Robert Haas (robertmhaas@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. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: