Re: BUG #16454: Mixed isolation levels inside transactions
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: lalbin@scharp.org
Cc: pgsql-bugs@lists.postgresql.org
Date: 2020-05-21T02:14:02Z
Lists: pgsql-bugs
PG Bug reporting form <noreply@postgresql.org> writes: > I am seeing mixed/hybrid Isolation Levels when setting the isolation level > to SERIALIZABLE READ ONLY DEFERRABLE, this also happens with REPEATABLE READ > READ ONLY. The user tables sees only the data committed before the > transaction begins but the system tables sees data committed by other > transactions after the transaction begins. This means in my example the user > tables are Serializable Isolation Level and the system tables are Read > Committed Isolation Level. As a general rule, all internal catalog accesses use latest-committed data (so effectively Read Committed) regardless of what the user-level visibility semantics are. This has to be so, because it just wouldn't do to not be working with the latest data. As an example, you don't get to ignore a CHECK constraint just because it got added after your transaction started. This does possibly result in some anomalies. We've judged that living with that is better than the alternatives, which would involve imposing far-more-draconian table locking and forced-transaction-rollback requirements than exist now for serializable transactions. In the example you give, the only practical alternative to the existing behavior would be to fail the reader transaction as soon as it tries to access the renamed schema. regards, tom lane
Commits
-
Doc: Add references for SI and SSI.
- 4c897197d793 9.5.23 landed
- 7295ac9c6c71 9.6.19 landed
- e2aca0d02d97 10.14 landed
- 648e56d3984d 11.9 landed
- eb1286413c0a 12.4 landed
- 4701efa9f741 13.0 landed
- 1575fbf1ac3c 14.0 landed