special cases of true serializability
От | Jeff Davis |
---|---|
Тема | special cases of true serializability |
Дата | |
Msg-id | 1262043379.22866.1363.camel@jdavis обсуждение исходный текст |
Ответы |
Re: special cases of true serializability
|
Список | pgsql-hackers |
I was thinking about true serializability, and started thinking that there are a lot of special cases where true serializability can be achieved without modification. For instance, the following is problematic: BEGIN; SELECT count(*) FROM mytable; ... because future insert/update/deletes may be based on that count, so we essentially would have to lock out write to mytable. However, BEGIN READ ONLY; SELECT count(*) FROM mytable; ... is fine, because snapshot isolation already gives true serializability. And inserts (that don't read any tables) are always safe as well. Also, in snapshot isolation mode, simple updates and deletes that have a simple predicate involving a unique key also give true serializability. It seems like the kinds of transactions that fall outside of these special cases are exactly the kind of transactions where serializability is most important -- reading an unknown number of tuples and then writing. People executing transactions like that are probably willing to pay some performance cost to ensure correct results. How hard would it be to reliably detect the transactions for which snapshot isolation already means true serializability? Regards,Jeff Davis
В списке pgsql-hackers по дате отправления: