The following bug has been logged on the website:
Bug reference: 7623
Logged by: Louis-Claude Canon
Email address: louis-claude.canon@univ-fcomte.fr
PostgreSQL version: 9.2.1
Operating system: All
Description: =
In the first paragraph of Section 13.2.1, it is first stated that "[with]
this isolation level, a SELECT query [...] never sees [...] changes
committed during query execution by concurrent transactions." It is my
understanding that this is untrue (as the rest of the paragraph seems to
imply).
Then, in the same subsection, an example is given in which a DELETE
statement is affected by an uncommitted UPDATE. It is unclear to me if this
still corresponds to the standard "Committed Read" isolation level. It could
be clearer with more precision: when is committed the DELETE statement? What
is the snapshot that it sees (when does the transaction start)? Or maybe
this standard isolation level only specified that SELECT statements must not
be affected by uncommitted changes?
As I am not an expert, I cannot guarantee that there is indeed any issue.
However, I believe it could be useful that an expert proof-reads or reviews
this subsection. For example, I am unsure whether any query will see a
consistent snapshot with only committed transactions (as it is stated at
first) or if uncommitted transactions may have an impact (as the last
example suggests).
I would also suggest to following change for clarity (or the contrary
change):
"The point at issue above is whether or not a single command sees an
absolutely consistent view of the database." -> "The point at issue above is
that any single command sees an absolutely consistent view of the database."
