From: | Hannes Erven <hannes(at)erven(dot)at> |
---|---|
To: | Dane Foster <studdugie(at)gmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: A contradiction in 13.2.1 |
Date: | 2016-01-27 22:45:49 |
Message-ID: | 56A9489D.5000003@erven.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dane,
> So the mental model I've built based on the first four sentences of
> the first paragraph is that when a transaction starts in read
> committed mode a snapshot is taken of the (database) universe as it
> exists at the moment of its creation and that it's only updated by
> changes made by the transaction that created the snapshot.
This is (almost) true for the REPEATABLE READ or SERIALIZABLE modes.
(However, the snapshot is taken as the first non-transaction-control
statement in the transaction starts.)
For "READ COMMITTED", the docs read (emphasis added):
"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."
(
http://www.postgresql.org/docs/9.5/static/transaction-iso.html#XACT-READ-COMMITTED
)
So if you re-run the same query multiple times within a single
transaction, you might get different results depending.
best regards,
-hannes
From | Date | Subject | |
---|---|---|---|
Next Message | Ivan Voras | 2016-01-27 22:54:37 | Catalog bloat (again) |
Previous Message | Dane Foster | 2016-01-27 22:30:47 | Re: Multi-Table Insert/Update Strategy - Use Functions/Procedures? |