postgres之无逻辑复制槽的逻辑复制

postgres自身提供的xlog(wal解析)功能，将数据的数据操作按着事务，依次放到逻辑复制槽中，（复制槽中可以用一些解析插件将wal解析为各种形式）然后能过walsender发出。这样的机制为之后的开发者降低了不少难度，但是逻辑复制槽在做逻辑复制的时候会占用过期的xid，如果逻辑复制槽断开后占用了一个很老的xid那会就会影响会postgres的autovacuum。

一个正确的和高性能的方式逻辑同步方式，应该舍弃逻辑复制槽，自行对wal(xlog)进行解析，有以下几个问题：

其一，由于wal是写入是乱序的，一个事务先后顺序不是以begin的先后决定，而是以后commit的先后决定。如果要自行解析和控制，那么就需要，自行控制事务的先后，及SQL语句的执行的顺序。应该以comit进行排序后，抽出以事务为单位的SQL集合进行解析和到目的执行。

其二，wal里的表名和字段名等数据库对象都是以OID的形式，如果要转成可读的格式需要，将OID转化为string格式的，数据库对象

如果每次查询POSTGRES系统表这样的操作。还是会影响数据库的性能。

基三，长事务，及大事务处理，长事务及大事务，他的SQL可能什么有一个很长时间或者大量的SQL操作。在解析的时候，如果没有得到commit。就不可以在中间去对外输出，但是中间的SQL在读取之后需要进行保留，这样就需要大量的内存或者在中间进行写盘。只能解析到commit之后才算是一个事务真正的成功。

其四，对于OID的过滤解析。比如模式，表名，字段名。等。或者是update,delete等操作的过滤。

其五，需要一个复制槽类似的工具来记录和做事务切换，这样才能保证不会丢事务或者重发事务。