早上刚睁开眼便收到局方，关于oracle–>Postgresql同步工具，有数据遗失的问题排查，pg数据库这边需要进行远程协助排查的诉求。
下面就说一下整个排查过程，可能会显得比较流水点，想回顾一下我此次排查问题的过程。以及重点加深pg的某些特点

背景：

到了之后，小伙伴就把从gateway的端口直接切换到pg数据库端口，并将日志级别调整为mod，开始再次测试。
第一轮测试完成，研发发出来几个主键id值，然后说，研发日志没有任何异常，但是这几条记录却已经丢失没有同步过去，‘切，难不成还是我数据库给你丢了，搞笑，肯定是你程序逻辑问题呀’ 哈哈哈哈，不由自主的心里想着,于是我开始意料之外(超出了意料内的排查时间)的排查日志之旅；

然后到数据库查询，‘麻蛋，日志有记录，数据库里面为啥没有数据；特么，肯定是后面update或者insert了’

被update delete 或者有触发器？

随后我就开始了，把这段时间产生的日志开始筛选，关于这个表的，有update或者delete所有语句进行了地毯式排查。
随着排查日志和其他问题的处理，时间慢慢都到了中午…
‘麻蛋，没有，怎么可能！’,心里有点慌了,‘那么有可能是触发器或者触发函数里面对这个记录行进行了致空操作，也可能产生这样的情况’。搞得午餐也食之无味。
下午上班之后就打算对数据库的函数、触发器进行相关的排查，“非常遗憾”，数据库中并没有触发器和函数。排查再次陷入了僵局。
‘MD,还有什么情况是数据库产生了日志，但是数据库里面有没有日志呢？’
然后再次跟研发确认了各个细节，包括数据库端口，还有整个程序实现的逻辑,还有确认是否程序端有日志报错什么的。研发了发了日志切图出来，

然后告知了程序的相关逻辑：
程序情况是这样的：

1.程序开始一个连接
2.程序设置这个连接conn的事务为非自动提交
3.程序开始创建prepareStatement执行语句(INSERT,UPDATE,DELETE)
4.程序连续执行了最大500条语句
5.程序执行conn的commit
结果是：
1.部分数据丢失，没有写入数据库
2.程序没有发现异常

后来他们有说数据库端口啥的，配置端口写成了，gateway端口之类的，我知道应该不是这个问题，我还是继续排查这我的日志。
‘是否是事务最后回滚？但是程序日志的commit是返回成功了的呀。不管了，直接开全量日志排查一下。’
于是开启了庞大的全量日志，完成之后，就是查找。日志也分享到了群里。
'beign;insert…;insert…;commit;'日志ok没有报错。
现在开始有说数据库bug的声音了
‘不可能，我不相信，怎么可能，如果这个insert这样的基本功能都有bug，那谁还敢用？’
随后，有新建了两个临时表，给研发，然他们进行替换。临时表里面还是不能插入；但是数据库日志里面依然有相关的insert记录。事情仿佛陷入了一个不可知的问题中。‘是否还能排查出来，难道真的是数据库bug’，我也莫名的开始了怀疑，‘不可能，这是数据库的基本功能，怎么可能，整个数据库的迭代，经过了无数次的验证和实践，绝不可能，一定是一个场景，让数据库插入失败，但是数据库记录了操作日志’;

关于逻辑解码

'怎么排查呢？'一个声音问着自己，还有什么方式？事务日志？解析不了，“开启逻辑解析!!!”（逻辑解码官方文档）
事情应该能预料到，毕竟数据库里面都没有写入，逻辑解码并没有相关记录的影子。

逻辑解码也没有相关的记录数据的影子这个肯定是没有写过来。

事件源头开始漏出

然后这边的几个人一起聊一下相关进度，此时已经快下班。
‘…日志里面有主键冲突的报错…’
'什么？？？！！！！‘我喊道，研发不是说没有报错吗？‘哪里有报错？我看一下’
一过滤，TMD，一堆的主键冲突报错，刚才特定去寻找这个表的相关操作，没有对错误进行排查，加上研发说日志没有任何报错，自己对错误的排查忽略了。‘嗨…还是怪自己没有排查好’
我为什么顿悟了？？？我为什么这么激动，因为pg数据库对待事务的处理方式和oracle mysql有差异，如果整个事务中有报错那么整个事务将会回滚，即便是commit，也会自动的rollback，而且commit不会产生任何的报错信息。


我告知研发，然他们增加、排查日志，我已经有了八层的把握，然后我说，下班，回家远程支持，等待他们的结果。因为我已经知道，我找到了原因，之前之所以没有怀疑这层，是研发一直很坚持整个过程没有报错和’部分数据丢失’。嗨…还是自己太年轻…
事情找到了原因，就是这个问题引发的。事务这块儿的处理方式PG数据库和其他数据库有点差异，如果做PG的话，一定要对这个有所了解。以便我们在一些场景中Troubleshooting能找到问题。我写这篇blog的目的就是凸显这个特点的重要性，希望大家也有个深刻的理解。