On 10/16/07, Nico Sabbi <nsabbi@xxxxxxxxxxxxxxxxxxx> wrote: > /From: > http://www.postgresql.org/docs/8.2/interactive/transaction-iso.html > > " > Read Committed/ is the default isolation level in PostgreSQL. When a > transaction runs on this isolation level, a SELECT query sees only data > committed before the query began; it never sees either uncommitted data > or changes committed during query execution by concurrent transactions. > (However, the SELECT does see the effects of previous updates executed > within its own transaction, even though they are not yet committed.) In > effect, a SELECT query sees a snapshot of the database as of the instant > that that query begins to run. Notice 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. > " > > to me the above sentence sounds inconsistent: it's asserting that both > 1) and 2) apply: > > 1) it never sees ... changes committed during query execution by > concurrent transactions During *query* execution. If you start a SELECT that runs through a table from beginning to end, and while it is running some other transaction quickly commits a row to the end, this SELECT will not see it when it gets there. > 2) Notice 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 Within a single *transaction*. If you run the above SELECT again, it will see the newly added row. ---------------------------(end of broadcast)--------------------------- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
