Question

http://www.postgresql.org/docs/9.1/static/transaction-iso.html The docs about Read Committed Isolation Level says

Read Committed is the default isolation level in PostgreSQL. When a transaction uses this isolation level, a SELECT query (without a FOR UPDATE/SHARE clause) sees only data committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions. In effect, a SELECT query sees a snapshot of the database as of the instant the query begins to run. However, SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed. Also note that two successive SELECT commands can see different data, even though they are within a single transaction, if other transactions commit changes during execution of the first SELECT.

The last sentence confuses me, What does it mean? What if I have not 2 selects in a transaction but 3 and also some calculations without using DML between them? Every select would see it's own snapshot on the moment of the beginning of every query?

Was it helpful?

Solution

The last sentence refers to this situation.

Assume there is a table foo that contains one row before both transactions start:

Transaction 1            Transaction 2
-------------------------------------------------------
begin transaction;
select *
from foo;
--> returns 1 rows
                         begin transaction;
                         insert into foo values (2);
                         commit;
select * 
from foo;
--> now returns 2 rows

(Note that transaction 1 has not been committed after the first select)

If you don't want to see the new (committed) row in transaction 1, you would need to use the isolation level called "repeatable read". The name stems from the fact that you can repeat the same query again and again and you will see the same data repeatedly.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top