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