Thread: BUG #7623: Inconsistency on transaction isolation documentation
BUG #7623: Inconsistency on transaction isolation documentation
From
louis-claude.canon@univ-fcomte.fr
Date:
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."