![]() | |
![]() |
| | Thread Tools | Display Modes |
#11
| |||
| |||
|
|
Your statement was true in 9.0 and before, but in 9.1, SERIALIZABLE means *truly serializable*. |

|
You need either a unique constraint I agree that a unique constraint is the right way to do it, because it's a declarative constraint. |
|
Your basic assumption for how transactions work is close to how simple databases work, that basically lock the whole table or database while you are working on it. Which is simple and cheap to do - as long as you aren't doing a whole lot in the database. If you have a lot of action going on in the database, the lock resolution eventually overwhelms the simplicity - which is the whole reason why there are databases like Postgresql, which can maintain good performance and data integrity without that locking. I strongly encourage you to do some experimentation on 9.1+ with serializable transactions (all transactions must be serializable for it to work). See if you can find any anomalies, or any performance degradation. The only expected performance degradation (aside from very strange cases) is that there will be serialization errors, and you'll need to retry those transactions. It does not cause any transactions to block that wouldn't otherwise. |
My statement above was to address why![]() |
| Thread Tools | |
| Display Modes | |
| |