Re: BUG #16454: Mixed isolation levels inside transactions
От | Tom Lane |
---|---|
Тема | Re: BUG #16454: Mixed isolation levels inside transactions |
Дата | |
Msg-id | 22443.1590027242@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #16454: Mixed isolation levels inside transactions (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
RE: BUG #16454: Mixed isolation levels inside transactions
|
Список | 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
В списке pgsql-bugs по дате отправления: