i) If both A and B run concurrently then either one can
finish before the other. Since the isolation is
serlizable, a transaction can only see rows committed
before its start.
So if they both start at the same time,and A commits
before B. Then B would throw an error at the commit
statement.
ii) If B was "read committed" and A had committed before
B's insert then B would throw an error during the
"insert" call.
Regards..
Amin
On Mon, 24 Mar 2003 09:38:06 +0100
u15074 <u15074@hs-harz.de> wrote:
>I have the following table:
>
>create table test(
>key int8,
>length int4,
>level int4,
>pu oid,
>primary key(key));
>
>Now I have two concurrent transactions:
>
>At the time the transactions start, there does't exist a
>row with value 1 for
>the key column.
>
>time transactionA:
>1 begin;
>2 set transaction level serializable;
>3 insert into test(1,..,..,..);
>4
>5 commit;
>
>time transactionB:
>1 begin;
>2 set transaction level serializable;
>3
>4 insert into test(1,..,..,..);
>5
>6 commit;
>
>So my question is, what happens with the insert of
>transactionB?
>Since a row with primary key value 1 doesn't exist within
>transactionB when
>executing the insert-statement, it shouldn't be a problem
>within the
>transaction.
>But if so, how will the constraint be fullfilled? Will
>transactionB be aborted?
>Is there a difference running in transaction level
>serializable or readcommited?
>
>-------------------------------------------------
>This mail sent through IMP: http://horde.org/imp/
>
>
>---------------------------(end of
>broadcast)---------------------------
>TIP 1: subscribe and unsubscribe commands go to
>majordomo@postgresql.org
