On 10/16/07, Nico Sabbi <nsabbi@officinedigitali.it> 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.