那指定失败呀

于是赶紧复用了之前的toast解析代码，顺利走通了解析，同时发现jsonb也有这个问题，于是一起给修复了。 终于，数据解析不再出现问题，接下来就交给PDU，静等结果。

表对象数量是否准确

需要救援的这个库存在着一个月之前还原的备份老库，老库的表对象和数据量与当前救援的这个库相差不多，是具有参考价值的。客户也担心PDU解析出来的表数量存在问题，因此特地让客户查了一下老库的表数量。

对比看看

首先前往老库查询了表对象的数量和toast对象的数量，分别是 14551和 14160,加起来是 28711个对象。

老库的表对象和toast对象数量

其次PDU解析出该库的pg_class表中toast对象+表对象的数量是 28891个

pg_class对象总数

并且我也取消了对系统模式的过滤，整体模式数量和对应表数量如下图所示，第一行显示toast对象是 14238 个，那么表对象则应该是 28891-14238=14653 个，我们将第一行以外的所有表对象数量相加，正是 14653个。

PDU初始化的输出结果

也就是说，从三个角度来看 整体的数量：当前 28891 老库 28711； 表的数量：当前 14653 老库 14551； toast的数量：当前 14238 老库 14160。 当前正在抽取的新库的数量都多于一个月前的老库，这是符合逻辑的。 并且新库中每个模式的表数量相加也与总数量一致，未有出现表数量缺失的情况。 因此可以判断，PDU对于每个模式以及对应表的解析是准确的。

最终结果

恢复效果

部分导出数据

客户的服务器性能足够给力，在PDU的全力并发支持下，以最快的时间将数据全部导出，并且恢复到一个新的实例中。 在数据导入的过程中也发现了一些乱码和转义的报错问题，也都迅速解决。

感想

当初凭着一腔热血往前冲，把PDU开发了出来，翘首以盼某一天能真正实战。  真到了实战的那天，才知道真实生产环境的残酷，睡觉都害怕有报错消息，不过还好是周末，没有影响日常工作。

真正经过了实战之后，信心倍增，本次恢复除了简单的日期字符数值类型之外，还包含各种疑难杂症结构体类型，真是开发得头都要爆炸了。

最后想说，PDU！太diao了！