在我的印象里，PG的运维知识图谱中是包含了这些等待事件的知识描述的，于是我打开系统检查了一下。下一秒钟，我惊讶地发现，在我们的知识图谱里并没有CommitTs这个等待事件，而是commit_timestamp。难道是PG 14的等待事件发生了变化？于是我查找了一下这方面的资料，发现从PG 13开始，PG的研发人员认为以前版本PG的等待事件名称有些随意，出于严谨的科学态度，从PG 13起作了较大的优化。在D-SMART中PG等待事件的知识图谱是以PG 10为蓝图构建的，并且在11、12版本出现后都做了升级。但是PG 13后等待事件的知识图谱就没有做过升级了，虽然后面陆续增加了人大金仓、GAUSSDB等的等待事件，但是并没有针对PG 13做升级。因此目前D-SMART的等待事件分析推理工具对PG 13或者以后的PG数据库版本的支持是存在问题的。
数据库的一些监控接口发生较大的变化是数据库生态工具厂商最头疼的事情，因为这些工具厂商必须投入巨大的成本才能不断地进行版本适配。以前工具仅仅支持Oracle数据库的时候，是没有这个问题的，因为针对Oracle数据库，我们只需要不断的加入新版本的功能就可以了，不需要针对以前已经完成的功能不断的进行版本迭代。Oracle的等待事件也是如此，新版本只会增加新的等待事件，不会修改已经存在的等待事件。最为典型的例子就是db file sequential read和db file scatterd read，这原本是Oracle内核研发中发生的一个乌龙事件，当时把离散读和顺序读的等待事件弄反了，但是后来Oracle很“科学”的解释了这个错误，但是出于知识延续性的问题，并没有对此进行纠正。久而久之这两个等待事件也成为了数据库IO等待事件关于离散读和顺序读的标准。在OWI方面也是如此，虽然目前v$session已经包含了完整的会话等待事件的信息，但是v$session_wait视图依然保留着。我有时候还会偶尔错用，用v$session_wait来分析等待事件。而新一代的DB可能都不一定知道这个接口到底是干啥用的。在OWI刚刚出来的Oracle 7.3.4里，这个接口就存在了，我们只能用v$session 来分析会话的其他信息，不能分析等待事件，因为等待事件只能从另外一个接口—v$session_wait中获得。
保持数据库接口的向下兼容性是对产品和客户负责的表现，虽然PG 13后的等待事件命名更科学一些，但是我不大认可这种做法。因为这会打破知识的传承，让使用者的学习成本增加。在接口上也是如此，变来变去的接口让数据库核心开发人员觉得更爽了，因为确实改变后更合理了，但是对于使用者来说，其学习成本就大幅度增加了。去年年底Oceanbase 4.0发布的时候，我就和蚂蚁的朋友吐槽，好不容易把OB 3.0复杂的监控视图搞明白了，OB 4.0来了个大颠覆，我又得从头学起了。OB的研发人员很惊讶的说：“你难道没觉得现在的监控视图用起来更舒服了吗？4.0的视图更加科学了！”。确实4.0的视图更科学了，但是我并不喜欢，因为我还要从头学习，以前的很多关于OB 的工具、和脚本也都要重新适配，这样的更科学的接口，实际上是不够科学的。更好的做法是保留这些接口，再新增一组“更科学”的接口。
商用数据库不是开发者的玩具，而是要被用户长期使用的，不断升级的技术不应该让使用者的知识不断的过期，保持知识与接口的兼容性方面，我们的国产数据库还是有很多地方要多学学Oracle。
