一、 背景
前些天晚上突然收到业务反馈，查询DB中的一个表报错
Could not open file "pg-xact/005E": No such file or directory.
两眼一黑难道是文件损坏了...登录查看DB日志，还好没有其他报错，业务也反馈只有这一个表在从库查询报错，主库正常，于是开始分析处理。
二、 解决方法
根据搜索结果看，这个问题基本就两种处理方法，这里先列出来。
1. 数据库恢复
如果数据库小，或者对数据一致性要求高，建议的方法还是进行恢复，因为方法二实际对数据一致性是有损的。
2. 新建空文件
报错是文件没了，所以解决方法是手动建回去（记得先确认权限）
#postgres用户执行
dd if=/dev/zero of=$PGDATA/pg_xact/005E bs=256k count=1
chmod 600 $PGDATA/pg_xact/005E风险
clog存事务的最终状态信息，就是这个事务最终是提交了还是回滚了，建一个空的文件，相当于文件里的事务不知道它提交还是回滚了，理论上会出现数据不一致。
三、 CLOG的原理及作用
postgresql源码学习（51）—— 提交日志CLOG 原理 用途 管理函数-CSDN博客
四、 遗留问题
这个报错为什么会突然出现，目前还没查到相关资料
1. 现场情况
- 报错PG版本为10.5，从库查询报错，主库不报错
- 报错中要找的clog为005E，txid为 99185979
- 报错数据库最旧的clog为0269，并且已经是两个月前的
- 报错数据库当前txid为 9436969370，远远大于报错的
一个小补充：为什么查出来的txid是94亿多，远远大于了42亿，实际上txid的计算有一个转换，转完之后大概是8亿多。
select (txid_current() % (2^32)::bigint)::text::xid;- 当时数据库中最老的表年龄大概是1.9亿，并且不是报错的这个表
2. 一些猜测
从现场情况来看，005E文件应该是PG正常删除，而非误删或文件系统损坏导致不可访问。
奇怪的是为什么查询该表会访问这么旧的文件，从事务年龄来看，这不应该是个正常的访问，比较怀疑还是遇到了奇怪的bug。
参考
PostgresQL-丢失各种数据文件如何恢复 - binbinx - 博客园
