From: | Amin Abdulghani <amin(at)quantiva(dot)com> |
---|---|
To: | u15074 <u15074(at)hs-harz(dot)de>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Concurrent insert question |
Date: | 2003-03-24 17:24:08 |
Message-ID: | web-1096569@quantiva.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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(at)hs-harz(dot)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(at)postgresql(dot)org
From | Date | Subject | |
---|---|---|---|
Next Message | Dennis Gearon | 2003-03-24 17:26:13 | Re: alter table change type column |
Previous Message | Bruce Momjian | 2003-03-24 17:16:58 | Re: alter table change type column |