True Serializable Transactions Are Here!
Do you have trouble figuring out when to lock what table with which type of lock? When to use SELECT FOR UPDATE or SELECT FOR SHARE? Do you need to maintain redundant data just to maintain data integrity? Do you wish you could just forget all that and assume that if a transaction performs correctly when it's run by itself that it will perform correctly no matter what other transactions are run at the same time?
Starting with PostgreSQL 9.1 you can!
Truly serializable transactions have been added to the 9.1 release. Should you use them? What are the trade-offs with techniques traditionally used in PostgreSQL? How can they be most effective?
This tutorial will address concurrency problems and how the new serializable functionality fits into the range of options available to deal with them.