RE: Revisited: Transactions, insert unique.
От | Hiroshi Inoue |
---|---|
Тема | RE: Revisited: Transactions, insert unique. |
Дата | |
Msg-id | 000201bfaf4c$603aba20$2801007e@tpf.co.jp обсуждение исходный текст |
Ответ на | Re: Revisited: Transactions, insert unique. (Joachim Achtzehnter <joachim@kraut.bc.ca>) |
Ответы |
RE: Revisited: Transactions, insert unique.
|
Список | pgsql-general |
> -----Original Message----- > From: pgsql-general-owner@hub.org [mailto:pgsql-general-owner@hub.org]On > Behalf Of Joachim Achtzehnter > > In a message to Ed Loehr and pgsql-general, Lincoln Yeoh wrote: > > > > Transaction A > > begin; > > insert into test (a,b) select 4,'four' from test > > where not exists (select * from test where a=4); > > > > Transaction B > > begin; > > insert into test (a,b) select 4,'four' from test > > where not exists (select * from test where a=4); > > > > Then you do a commit on both, and you end up with two rows. > > This is dissapointing indeed! What this means is that Postgresql > transactions are, in fact, not truely serializable. The concurrent > execution of these two transactions is not equivalent to some serial > execution. > Strictly speaking SERIALIZABLE isolation level of PosgreSQL isn't SERIALIZABLE. It's same as Oracle. AFAIK,there's no way to block (logically) non-existent row(key) except unique constraint. Regards. Hiroshi Inoue Inoue@tpf.co.jp P.S. Note that the default isolation level of PostgreSQL is READ COMMITTED.
В списке pgsql-general по дате отправления: