背景
数据库的事务是原子操作，要么成功，要么失败。但是实际上在客户端的视角，可能有第三种状态：unknown状态。
当客户端提交事务结束（rollback , commit , prepare xact , rollback pxact , commit pxact）的请求后，数据库收到请求，数据库可能执行失败，也可能执行成功，不管怎样都要写对于的WAL日志，还有CLOG，然后数据库要将执行结果返回给客户端ACK。
这里存在几种可能，导致客户端不知道执行到底怎么样了？
收到客户端请求后，数据库没有返回任何ACK给客户端，客户端对这次请求很茫然，它只能人为数据库处于UNKNOWN的状态。
UNKNOWN 事务的处理
unknown事务，就是客户端没有收到commit/rollback ACK的事务。不知道是成功还是失败。
多节点(quorum based sync replication)与单节点都可能出现UNKNOWN事务，效果、形态一致。
如何处理unknown事务呢？
unknown事务分为以下几种情况.
rollback , commit , prepare xact , rollback pxact , commit pxact 几种情况的unknown处理方法：
1、两阶段解决unknown状态问题
prepare 阶段unknown, 切换leader后，客户端通过pg_prepared_xacts视图检查prepare xact状态，如果没有prepare xact则说明失败了，那么整个事务重新发起即可。如果prepare xact存在，说明prepare xact成功了。
commit or rollback prepare xact阶段unknown, 切换后检查prepare xact状态，存在则重试commit or rollback prepare xact。不存在则说明已经成功（我们认为2PC是一定成功的），无须处理。
2、非两阶段事务，rollback unknown无须处理，rollback失败或成功对于客户端来说结果是一样的。因为不管怎样都会回滚掉，这是数据库原子性保障的。
3、非两阶段事务，commit unknown处理，极度严谨的场景，程序可以设计事务状态可回溯，例如：
事务开始时，记录事务号或唯一流水号，事务号在数据库中是一个唯一的流水，可以根据事务号查询它的状态，比如postgresql。
但是并不是所有数据库都有这种接口，比如非物理流式复制的数据库，则可以在事务中增加全局唯一流水号来查看事务是否提交。这里利用了事务的原子特性，既要么全成功要么全失败。可以举个使用例子。
使用业务流水实现事务状态判断的例子：
begin;
生成唯一业务流水ID, 写入到某个流水表，同时在程序或其他数据库中记录这个流水号，备查。
执行事务
提交事务；
-- 出现unknown
通过唯一业务流水ID，查询数据库中是否存在这条记录。
如果不存在，说明事务提交失败。
如果存在，说明事务提交成功。（因为数据库的事务是原子操作）
