Documentation Inaccuracy – Transaction Isolation

Started by Nicholson, Brad (Toronto, ON, CA)about 11 years ago2 messagesgeneral
Jump to latest

Hi,

I noticed an inaccuracy in the transaction isolation docs. Under the Repeatable Read Isolation Level section it states:

“The Repeatable Read isolation level only sees data committed before the transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions.”

That is not entirely accurate. The snapshot starts with the first SQL statement in the transaction, not at the start of the transaction. Any change that is committed in another transaction after the start of the transaction but before the first SQL statement will be seen.

Brad.

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

#2Bruce Momjian
bruce@momjian.us
In reply to: Nicholson, Brad (Toronto, ON, CA) (#1)
Re: Documentation Inaccuracy – Transaction Isolation

On Tue, Apr 28, 2015 at 08:00:24PM +0000, Nicholson, Brad (Toronto, ON, CA) wrote:

Hi,

I noticed an inaccuracy in the transaction isolation docs. Under the Repeatable Read Isolation Level section it states:

“The Repeatable Read isolation level only sees data committed before the transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions.”

That is not entirely accurate. The snapshot starts with the first SQL statement in the transaction, not at the start of the transaction. Any change that is committed in another transaction after the start of the transaction but before the first SQL statement will be seen.

Yes, we have fixed that for PG 9.5:

http://www.postgresql.org/docs/devel/static/transaction-iso.html

This level is different from Read Committed in that a query in a
--> repeatable read transaction sees a snapshot as of the start of the first
--> non-transaction-control statement in the transaction, not as of the
start of the current statement within the transaction. Thus, successive
SELECT commands within a single transaction see the same data, i.e.,
they do not see changes made by other transactions that committed after
their own transaction started.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ Everyone has their own god. +

--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general