PostgreSQL 的多版本并发控制（MVCC：Multi-version Concurrency Control）
从用户使用角度来看，PostgreSQL的事务并发特性，应具备如下性质： 每一个事务在开始时，记录（snapshot）当时数据库的Version，事务一旦开始运行后，其他事务做了什么操作应该不影响本事务； 读永不堵塞写，写永不堵塞读——这句话老是在Oracle的文档中看到； 写操作与写操作之间，只有当修改了相同数据行时，才会出现互相堵塞——行级锁。 下面举一个最典型的并行Update相同数据行的例子： Transaction A 执行操作： UPDATE foo SET x = x+1 WHERE rowed = 42 在Transaction A提交或回滚之前，Transaction B执行操作： UPDATE foo SET x = x+1 WHERE rowed = 42 很显然： B需要等待A提交或者回滚 如果A回滚事务，那么B继续执行，x的值也毫无争议 但是如果A事务提交，那B事务会发生什么？ x的值仍然使用原来的值，会出现update语句执行两次，但是x的值只增加了1，这显然不是我们预期的结果 但是如果B事务使用A事务提交后的x的新值，那么B事务就使用了其开始之后才提交的数据。这和Transaction Isolation原则冲突…… 回答上面的问题，我们来了解PostgreSQL的transaction isolation level实现： PostgreSQL提供两种isolation level（这和Oracle一致）： Read committed level： 针对前述问题，B事务将使用A事务提交后的新数据（A事务提交后的数据行，必须仍然满足B事务的where条件限制） Serializable level：