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  (Robert Haas <robertmhaas@gmail.com>)
Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid  (Andrew Dunstan <andrew@dunslane.net>)
Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid  (Greg Smith <greg@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Streaming replication as a separate permissions