【PostgreSQL复制槽相关机制在各版本调整】

提到PostgreSQL流复制和逻辑复制这两种复制方式，不得不想到的一个东西，就是复制槽（Replication Slot）。
复制槽在PostgreSQL 9.4版本中被引入，引入之初是为了防止备库需要的WAL日志在主库被删除，确保主库在所有的备库收到wal之前不会移除它们，主库会会根据备库返回的信息确认哪些WAL已不再需要，才能进行清理。Replication Slot能够确保在主备断连后主库的WAL仍不被清理，因为Replication Slot的状态信息是持久化保存的，即便从库断掉或主库重启，这些信息仍然不会丢掉或失效。
复制槽分为物理复制槽（Physical Replication Slot）和逻辑复制槽（Logic Replication Slot）。物理复制槽一般结合流复制一起使用，能够很好的保证备库需要的日志不会在主库删除。
而逻辑复制槽是PostgreSQL自身提供的WAL(WAL解析)功能，将数据的数据操作按照事务，依次放到逻辑复制槽中，（复制槽中可以用一些解析插件WAL解析为各种形式）然后能过walsender发出。他最主要的作用是来记录和做事务切换，这样才能保证不会丢事务或者重发事务。
复制槽实质上是内存中的一些数据结构，加上持久化保存到pg_replslot/目录中的二进制状态文件。在PostgreSQL启动的时候，预先在共享内存中分配好这些数据结构所用内存（即一个大小为max_replication_slots的数组）。需要注意的一点是，我们在进行basebackup的时候是会把pg_replslot这个目录排除掉的，所以就算主库上存在逻辑复制槽，在用basebackup搭建流复制的时候，也是不会把原本的主库上的逻辑复制槽拷贝到备节点。如下为PostgreSQL数据库源码里的一部分，位置在src/backend/replication/basebackup.c，这里面包含了basebackup命令执行过程会忽略的目录，

static const char *const excludeDirContents[] =
{
	PG_STAT_TMP_DIR,
	"pg_replslot",
	PG_DYNSHMEM_DIR,
	"pg_notify",
	"pg_serial",
	"pg_snapshots",
	"pg_subtrans&#