I have a question. Transaction isolation level is set to serializable. When the one user opens a transaction and INSERTs or UPDATEs data in "table1" and then another user opens a transaction and tries to INSERT data to the same table, does the second user need to wait 'til the first user commits the transaction?
A:
The second user will be blocked until the first user commits or rolls back his/her changes.
Martin Doms
2010-06-10 02:46:17
+1
A:
Generally, no. The second transaction is inserting only, so unless there is a unique index check or other trigger that needs to take place, the data can be inserted unconditionally. In the case of a unique index (including primary key), it will block if both transactions are updating rows with the same value, e.g.:
-- Session 1 -- Session 2
CREATE TABLE t (x INT PRIMARY KEY);
BEGIN;
INSERT INTO t VALUES (1);
BEGIN;
INSERT INTO t VALUES (1); -- blocks here
COMMIT;
-- finally completes with duplicate key error
Things are less obvious in the case of updates that may affect insertions by the other transaction. I understand PostgreSQL does not yet support "true" serialisability in this case. I do not know how commonly supported it is by other SQL systems.
See http://www.postgresql.org/docs/current/interactive/mvcc.html
Edmund
2010-06-10 02:51:37
hm.. so if i had a primary key in this table unique index check will be performed and second user will be blocked?
Alexander
2010-06-10 03:11:35
In my experience, quite a lot of tables do have unique indexes.
Stephen Denne
2010-06-10 03:12:00
thanks for help!
Alexander
2010-06-10 06:11:02
the second transaction blocks only because it's trying to insert a duplicate key. If the keys didn't clash, there would be no blocking.
araqnid
2010-06-10 11:41:01