The ANSI/ISO SQL standard defines four levels of transaction isolation in terms of three phenomena that must be prevented between concurrent transactions. These undesirable phenomena are:
A transaction reads data written by concurrent uncommitted transaction.
A transaction re-reads data it has previously read and finds that data has been modified by another transaction (that committed since the initial read).
A transaction re-executes a query returning a set of rows that satisfy a search condition and finds that the set of rows satisfying the condition has changed due to another recently-committed transaction.
The four transaction isolation levels and the corresponding behaviors are described in Table 9-1.
Table 9-1. SQL Transaction Isolation Levels
| Isolation Level | Dirty Read | Non-Repeatable Read | Phantom Read |
|---|---|---|---|
| Read uncommitted | Possible | Possible | Possible |
| Read committed | Not possible | Possible | Possible |
| Repeatable read | Not possible | Not possible | Possible |
| Serializable | Not possible | Not possible | Not possible |
PostgreSQL offers the read committed and serializable isolation levels.
In your comparison of Oracle and PostgreSQL it is stated that PostCommitSelect in Oracle would NOT show the changes... It's not true. When using default Oracle's transaction isolation (which is read committed) Oracle will behave exactly the same as PostgreSQL in the situation described in your review. May be you used serializable mode of Transaction isolation within Oracle, but I think it is worth mentioning it then.