PREPARE TRANSACTION为当前事务的两阶段提交做准备。在命令之后， 事务就不再和当前会话关联了； 它的状态完全保存在磁盘上，它提交成功有非常高的可能性，即使是在请求提交之前数据库发生了崩溃也如此。
一旦准备好了，一个事务就可以在稍后用 COMMIT PREPARED或ROLLBACK PREPARED命令分别进行提交或者 回滚。这些命令可以从任何会话中发出，而不光是最初执行事务的那个会话。
从发出命令的会话的角度来看，PREPARE TRANSACTION不同于ROLLBACK：在执行它之后，就不再有活跃的当前事务了，并且预 备事务的效果无法见到(在事务提交的时候其效果会再次可见)。
如果PREPARE TRANSACTION因为某些原因失败，那么它就会变成一个ROLLBACK， 当前事务被取消。
一个任意的标识符，用于后面在COMMIT PREPARED或ROLLBACK PREPARED的时候标识 这个事务。 这个标识符必须以字符串文本的方式书写，并且必须小于200字节长。它不能和任何当前预备事务已经使用了 的标识符同名。
PREPARE TRANSACTION不是打算用于应用程序或者交互会话的。其目的是允许一个 内部事务管理器来跨多个数据库或其他事务性资源执行自动全局事务。除非你在写一个事务管理器， 你可能不会使用PREPARE TRANSACTION。
该命令必须在一个事物内部使用。使用BEGIN来启动一个。
目前还不允许PREPARE一个已经执行包括临时表在内的任意事务，创建任何游标 WITH HOLD，或者执行LISTEN或者UNLISTEN。 那些特性与当前在预备事务中有用的会话联系太紧。
若事务通过SET调整任意运行时参数（没有LOCAL选项）， 那些影响在PREPARE TRANSACTION之后仍然保留，并且将会受后来的 COMMIT PREPARED或者ROLLBACK PREPARED影响。 因此，在这一点上，PREPARE TRANSACTION表现的更像COMMIT而非 ROLLBACK。
所有目前可用的预备事务都在系统视图 pg_prepared_xacts里面列出。
| Caution |
使食物长时间处于预备状态是不明智的。这将干扰VACUUM回收存储的能力， 并且在极端情况下可能导致数据库关闭以组织食物ID环绕式处理（参阅Section 23.1.4）。也请记住事务将继续持有它持有的任何锁, 该特性的预期使用方法是：内部事务管理器一旦核实其他数据库也预备提交，一个预备事 务通常就将会提交或者回滚。 如果您没有设置一个内部事务管理器来跟踪预备事务并确保他们得到及时关闭，最好是 通过将max_prepared_transactions设置为0来保持预备事务功能禁用。 这将阻止预备事务的意外创建，那可能会被遗忘或者最终引发问题。 |