RE: Revisited: Transactions, insert unique.
Hiroshi Inoue <inoue@tpf.co.jp>
From: "Hiroshi Inoue" <Inoue@tpf.co.jp>
To: "Peter Eisentraut" <peter_e@gmx.net>
Cc: "Ed Loehr" <eloehr@austin.rr.com>, "Joachim Achtzehnter" <joachim@kraut.bc.ca>, <pgsql-general@postgresql.org>, "Tom Lane" <tgl@sss.pgh.pa.us>
Date: 2000-04-27T08:48:24Z
Lists: pgsql-general
> -----Original Message----- > From: Peter Eisentraut [mailto:e99re41@DoCS.UU.SE] > Sent: Thursday, April 27, 2000 4:46 PM > To: Hiroshi Inoue > > On Thu, 27 Apr 2000, Hiroshi Inoue wrote: > > > PostgreSQL's SERIALIZABLE isolation level would allow both inserts. > > READ COMMITED isolation level wouldn't allow A's inserts. > > > > As I mentioned in another posting,PostgreSQL's SERIALIZABLE > > isolation level isn't completely serializable and it's same as Oracle. > > Probably Vadim refers to this incomplete serializability somewhere > > in documentation. > > It seems almost impossible to implement complete serializability > > under MVCC without using table level locking. I love MVCC much > > more than theoretically beautiful complete serializability. > > Given that Postgres correctly recognizes concurrent updates and aborts one > of the transactions, Is what you mean the following ? When a transaction is about to update a row which has been updated by other transactions under SERIALIZABLE isolation level,update is rejected with message ERROR: Can't serialize access due to concurrent update. > how difficult would it be to do the same for inserts? Should INSERT/UPDATE/SELECT .. FOR UPDATE statements wait until being inserted rows to be commit/aborted ? This means INSERT operations block all update operations for the same table. Regards. Hiroshi Inoue Inoue@tpf.co.jp