/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
Am Dienstag, 16. Oktober 2007 schrieb Nico Sabbi:
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
What this is supposed to mean is that you don't see changes while
On 10/16/07, Nico Sabbi [EMAIL PROTECTED] 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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/16/07 07:08, Trevor Talbot wrote:
On 10/16/07, Nico Sabbi [EMAIL PROTECTED] wrote:
/From:
http://www.postgresql.org/docs/8.2/interactive/transaction-iso.html
Read Committed/ is the default isolation level in PostgreSQL. When a
Nico Sabbi wrote:
/From:
http://www.postgresql.org/docs/8.2/interactive/transaction-iso.html
Read Committed/ [...]
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
Albe Laurenz ha scritto:
Nico Sabbi wrote:
/From:
http://www.postgresql.org/docs/8.2/interactive/transaction-iso.html
Read Committed/ [...]
to me the above sentence sounds inconsistent: it's
asserting that both 1) and 2) apply:
1) it never sees ... changes committed during query
On 10/16/07, Nico Sabbi [EMAIL PROTECTED] wrote:
well, I know how read committed behaves, but
I don't see why should anyone expect an update of the resultset
of the currently executing query after a commit by a different
transaction.
A currently executing UPDATE will see changes made to
