backend_xid表示已申请事务号的事务，例如有增删改，DLL等操作的事务。backend_xid从申请事务号开始持续到事务结束。
backend_xmin表示SQL执行时的snapshot，即可见的最大已提交事务。
而表膨胀的原因是什么呢？当数据库中存在未结束的SQL语句或者未结束的持有事务ID的事务，在此事务过程中，或在此SQL执行时间范围内产生垃圾的话，这些垃圾无法回收，导致数据库膨胀。
也就是判断当前数据库中backend_xid和backend_xmin最小的值，凡是超过这个最小值的事务产生的垃圾都不能回收。
因此，我们如果想要监控长事务该怎么写呢？以超过1小时的长事务为例：
所以，对于事务而言，只有当执行了一些DML或者DDL操作后才能算是我们通常说的长事务。否则只能算是我们常说的长连接，当然长连接也有很多弊端，例如占用内存、cpu等资源。
在实际应用中，我们应当做好对长事务的监控，并尽可能的避免其发生。例如一些批量的操作可能会比较容易导致长事务，我们可以尽量将其安排在业务低峰期执行，同时，如果我们的应用中关闭了自动提交，也要在执行完之后加上提交。
到此这篇关于PostgreSQL长事务概念解析的文章就介绍到这了,更多相关PostgreSQL长事务内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
