在操作系统上已经可以看到该文件。
插入一些数据：
因为segment_size的设置为1GB，磁盘上已经有了多个文件
现在，开启另一个会话(session 2)。
在session2中，启动一个事务并创建一个空表，但是不提交事务：
在操作系统已经可以看到对应的文件：
如果这个时候，posrgresql server发生了奔溃、或者发生了oom被kill了或者session被kill了。会发生什么呢？
我们来模拟一下session被kill的场景：
再次在session2中执行查询：
这个session在事务提交之前被kill了，事务无法正常完成，但是事务已经创建了一个表。应该发生什么呢？事务被回滚，创建的表应该不存在了。
这正是我们所预期的。但在操作系统上，文件仍然存在：
这样，文件就成了孤儿文件(orphaned file)。
postgresql并不知道这个文件属于哪个relation
这样，你就需要自己手动清理孤儿文件了！
假设你做了大量的数据的加载，就在加载完成之前，会话被杀死:
虽然会话被kill了。但是磁盘上的空间并没有被释放。
在最糟糕的时候，可能会占用大量的磁盘空间。那是否有什么方法去检测这些孤儿文件呢？
你需要比较postgresql中的目录表中的记录和文件系统上信息，然后删除这些孤儿文件。这个过程需要小心谨慎。
首先获得你要检测的数据库的oid：
这样就可以知道文件在文件系统上的位置。即 $PGDATA/base/[OID_OF_THE_DATABASE]
然后，获得孤儿文件：
补充：理解postgreSQL中的prepared transactions和处理孤儿(orphans)事务
Prepared transactions是PostgreSQL的一个关键特性。理解该特性提供的功能和处理任何潜在的陷阱对于系统的维护是很关键的。所以，我们来深入研究一下具体什么是prepared transactions。
关于事务在数据库系统中，事务是一种处理通常包含多个语句的块中的全部或零个语句的方法。在提交整个块之前，该块中语句的结果对其他事务不可见。 如果事务失败或回滚，则对数据库完全没有影响。
事务依附于会话。但是，当要执行与会话独立的事务时（也有其他好处）。这就是“prepared transactions”的来源。
prepared transactionsprepared transaction是独立于会话、抗崩溃、状态维护的事务。事务的状态存储在磁盘上，这使得数据库服务器即使在从崩溃中重新启动后也可以恢复事务。在对prepared transaction执行回滚或提交操作之前，将一直维护该事务。
PostgreSQL文档声明，在一个已存在的事务块中，可以使用prepare transaction 'transaction_id‘命令创建一个prepared transaction。它进一步声明该过程为两阶段提交准备了一个事务。
此外，建议应用程序或交互式会话不要使用prepared transaction。理想情况下，外部事务管理器应该跨同构或异构数据库资源执行原子的全局事务。
在postgreSQL中，缺省的max_prepared_transaction=0；即关闭了prepared transaction。如果你想使用prepared transaction，建议将max_prepared_transaction设置成max_connections的值。在同步的流复制standby库上，最好将其设置的比max_connections大一点，以免standby不能接收查询。
在任何给定的时间，你可以查看活跃状态的prepared transactions，通过查看视图pg_prepared_xacts。
pg_prepared_xacts视图含有以下一些列：
1.transaction：事务id
2.gid：用户为prepared transaction定义的名称
3.prepared：prepared日期，创建事务时带有时区的时间戳
4.owner：创建该prepared transaction的事务
5.database：数据库名
创建prepared transaction知道什么是prepared transaction之后，现在来看看如何创建一个prepared transaction。创建一个该事务通常需要四个步骤：
1.begin(或start transaction)
2.执行需要的操作
3.prepare transaction
4.commit(或rollback prepared)
prepare transaction、commit prepared、或rollback prepared后面加上一个gid，可以唯一标识prepared transaction。
例如下面的代码块：
当一个含有一个或多个活跃的prepared transactions的postgresql停止了或者奔溃了，会为每个活跃的prepared transaction创建一个文件，在目录pg_twophase中。
比如，我们有个prepared transaction：
所以我没有提交事务就停止了postgresql server。postgresql就会创建一个名为00003FEB的文件，对应于prepared transaction的事务id。
00003FEB等价于16363。在postgresql被重启后，在启动日志会报如下信息：
如果你不希望恢复一个prepared transaction，可以简单地删除pg_twophase文件夹下的相应文件。
这很简单，不是吗?那么我们为什么不经常地使用它呢?毕竟，它提供了更高的提交操作成功的可能性。事情要是这么简单就好了!
prepared transaction可能遇到哪些错误？如果客户端消失了，则prepared transaction可以未完成(既不提交也不回滚)。发生这种情况的原因多种多样，包括客户机崩溃，或者服务器崩溃导致客户机连接被终止而无法重新连接。你实际上是依靠事务管理器来确保没有孤立的prepared transaction。
除了崩溃之外，还有另一种原因可以使prepared transaction未完成。如果一个用于恢复的备份包含了事务的prepared阶段，但是没有包含关闭事务的阶段，仍然会生成孤儿事务。
或者，DBA创建了一个prepared transaction，却忘记了关闭它。
所以，如果一个prepared transaction没有完成，又会有什么大不了的呢?
真正的问题
真正的问题是，孤儿prepared transaction继续持有可能包含锁的关键系统资源，或者使事务ID保持活动状态，该事务ID可能会阻止vacuum清除只对该孤儿事务可见、对其它事务不可见的死的元组。
回想一下我在上面创建的prepared 事务。当事务prepared，并且在提交该事务之前，如果另一个事务试图更改该表，它将无法获取所需的锁并挂起，直到解决了prepared事务（提交或回滚）为止。 否则，alter命令会无限期挂起，最终，我必须发出CTRL + C来停止该命令。
对vacuum的阻塞可能会更严重，在极端情况下，会导致数据库关闭，因为孤儿prepared事务会阻止事务id的wrap around。
发现和通知虽然一般的预期是prepared事务在几秒钟内完成，但是情况并不总是这样。一个prepared事务可能持续几分钟、几小时甚至几天。
为这些事务维护元数据本身可能是一项挑战。但是，我建议设置一个术语来定义prepared事务可以存在的最大时间。例如，考虑以下的prepared事务:
或者下面的事务：
在这些事务名称中，最后一部分定义事务的时间。任何超出时间的事务可以通过sql查询轻易地找出来：
这里就很清晰地显示了一个不应该再有效的事务。因此，使用一个外部代理或者cron任务可以轻易找出这些事务，或者通知管理员、或者回滚事务。
在我看来，这是一种简单而容易的方式，可以确保即使事务管理器失败或DBA意外地留下了一个事务，也可以在你的环境中管理孤儿事务。
结论Prepared transactions显然是一个非常重要的功能，但是需要使用回退通知程序或清理程序仔细设置环境，以轻松确保这些事务不会不必要地占用关键资源，并且系统保持良好状态。
PostgreSQL社区中仍在讨论如何处理孤儿prepared事务。它是否成为postgresql核心的一部分尚待观察。同时，我们需要使用外部工具来管理这些事务，或者设法解决这个问题。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持七叶笔记。如有错误或未考虑完全的地方，望不吝赐教。
