这些设置控制内置流复制特性（见Section 26.2.5）的行为。服务器将可以是主库或备库。主库能发送数据，而备库总是被复制数据的接收者。当使用级联复制（见Section 26.2.7）时，备库也可以是发送者，同时也是接收者。这些参数主要用于发送服务器和备库，尽管某些只在主库上有意义。如果有必要，设置可以在集簇中变化而不出问题。
这些参数可以在任何发送复制数据给一个或多个备库的服务器上设置。主库总是一个发送服务器，因此这些参数总是要在主库上设置。这些参数的角色和含义不会在一个备库变成主库后改变。
max_wal_senders (integer) #指定来自备库或流式基础备份客户端的并发连接的最大数量（即同时运行 WAL 发送进程的最大数）。 默认值是10。值0意味着禁用复制。 突然的流客户端断开连接可能留下一个孤立连接槽（知道达到超时），因此这个参数应该设置得略高于最大客户端连接数，这样断开连接的客户端可以立刻重新连接。 这个参数只能在服务器启动时被设置。此外，wal_level必须设置为replica或更高级别以允许来自备库的连接。
在运行一个备库时，你必须把这个参数设置为等于或者高于主库上的值。 否则，备库上可能不会允许查询。
max_replication_slots (integer) #指定服务器可以支持的复制槽（见Section 26.2.6） 最大数量。默认值为10。这个参数只能在服务器启动时设置。将它设置为一个比当前已有复制槽要少的值会阻碍服务器启动。此外，要允许使用复制槽， wal_level必须被设置为replica或 更高。
wal_keep_size (integer) #指定在备库需要为流复制获取日志段文件的情况下，pg_wal目录下所能保留的过去日志文件段的最小尺寸。 如果一个连接到发送服务器的备库落后了超过wal_keep_size兆字节，发送服务器可以移除一个备库仍然需要的 WAL 段，在这种情况下复制连接将被中断。 最终结果是下行连接也将最终失败（不过，如果在使用 WAL 归档，备库可以通过从归档获取段来恢复）。
只设置pg_wal中保留的文件段的最小尺寸；系统可能需要为 WAL 归档或从一个检查点恢复保留更多段。 如果wal_keep_size为零（默认值）， 更多的空间来 存放WAL归档或从一个检查点恢复。 如果wal_keep_segments是零（缺省）， 系统不会为备库目的保留任何多余的段，因此备库可用的旧 WAL 段的数量是一个上个检查点位置和 WAL 归档状态的函数。 如果此值被指定时没有单位，则视为兆字节。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
max_slot_wal_keep_size (integer) #指定在检查点时，replication slots（复制槽）允许在pg_wal目录中保留的WAL文件的最大大小。 如果max_slot_wal_keep_size为-1（默认值），复制槽可以保留无限量的WAL文件。否则，如果复制槽的restart_lsn落后于当前LSN超过给定大小， 使用该槽的备机可能由于所需的WAL文件被删除而无法继续复制。您可以在pg_replication_slots中查看复制槽的WAL可用性。 如果未指定单位，则此值将被视为兆字节。此参数只能在postgresql.conf文件或服务器命令行中设置。
idle_replication_slot_timeout (integer) #使保持空闲状态（未被复制连接使用）超过此持续时间的复制槽失效。 如果指定值时没有单位，则以秒为单位。零值（默认值）将禁用空闲超时失效机制。 该参数只能在postgresql.conf文件中或服务器命令行上设置。
由于空闲超时导致的槽失效会在检查点期间发生。由于检查点每隔 checkpoint_timeout触发一次，因此从 idle_replication_slot_timeout超时到下一个检查点使槽失效之间可能会有一些延迟。 若要避免这种延迟，用户可以强制执行检查点，以便及时使不活动的槽失效。槽的不活动时间根据其 pg_replication_slots.inactive_since值计算。
请注意，空闲超时失效机制不适用于不保留 WAL 的槽，也不适用于正在从主库同步的备库上的槽 （即pg_replication_slots.synced 值为true的备库槽）。已同步的槽总是被视为空闲，因为它们不会执行逻辑解码来生成变更。
wal_sender_timeout (integer) #中断那些停止活动超过这个时间量的复制连接。这对发送服务器检测一个费用服务器崩溃或网络中断有用。 如果指定值时没有单位，则以毫秒为单位。默认值是 60 秒。值0将禁用超时机制。
对于跨越多个地理位置分布的集簇，每个位置使用不同的值可以为集簇管理带来更大的灵活性。 对于具有低延迟网络连接的备库，较小的值有助于更快的故障检测; 对于位于远端位置的具有高延迟网络连接的备库，较大的值有助于更好地判断备库的健康状况。
track_commit_timestamp (boolean) #记录事务的提交时间。该参数只能在服务器启动时设置。默认值是off。
这些参数可以在发送复制数据给一个或多个备库的主库上设置。注意除了这些参数之外，在主库上必须设置合适的wal_level，并且也启用可选的 WAL 归档（见Section 19.5.3）。这些参数值与备库无关，尽管你可能希望为了准备好一个备库转变成主库来设置这些参数。
synchronous_standby_names (string) #如Section 26.2.8所述，这个参数指定一个支持同步复制的备库的列表。 可能会有一个或者多个活动的同步备库，在这些备库确认收到它们的数据之后，等待提交的事务将被允许继续下去。 同步备库是那些名字出现在这个列表前面，并且当前已连接并且正在实时流传输数据（如pg_stat_replication视图中streaming的状态所示）的服务器。 指定多于一台同步备库可以得到非常高的可用性并且能防止数据丢失。
用于这一目的的备库的名称是其application_name设置，它在备库的连接信息中设置。 在物理复制备库的情况下，这应该被设置在primary_conninfo设置中，如果设置了，默认是cluster_name的设置，否则为 walreceiver。 对于逻辑复制，可以在订阅的连接信息中设置。对于其他复制流消费者，请参考其文档。
这个参数使用下面的语法之一来指定一个备库列表：
[FIRST]num_sync(standby_name[, ...] ) ANYnum_sync(standby_name[, ...] )standby_name[, ...]
其中num_sync是事务需要等待其回复的同步备库的数量，standby_name是一个备库的名称。FIRST以及ANY指定从所列服务器中选取同步备库的方法。
关键词FIRST加上num_sync指定一种基于优先的同步复制，并且会让事务提交等待，直到它们的WAL记录被复制到基于优先级选择的num_sync台同步备库上为止。例如，设置FIRST 3 (s1, s2, s3, s4)将导致每次提交都等待来自三台较高优先级的备库的答复，这三台备库将从备库s1、s2、s3以及s4中选出。在该列表中出现较早的备库将被给予较高的优先级，并且将被考虑为同步备库。列表中出现的其他备库表示潜在的同步备库。如果当前的任何同步备库因为某种原因断开连接，它将立刻被下一个最高优先级的备库替代。关键词FIRST是可选的。
关键词ANY加上num_sync指定一种基于规定数量的同步复制，并且会让事务提交等待，直到它们的WAL记录被复制到所列出备库中的至少num_sync台上为止。例如，设置ANY 3 (s1, s2, s3, s4)将导致每次提交会在收到s1、s2、s3以及s4中任意三台备库的回答后立刻继续下去。
FIRST和ANY是大小写不敏感的。如果这些关键词被用作备库的名字，其standby_name必须被放在双引号内。
PostgreSQL版本 9.6 之前使用过第三种语法，目前也仍然支持。它和FIRST和num_sync等于1的第一种语法相同。例如，FIRST 1 (s1, s2)和s1, s2具有相同的含义：s1或者s2会被选中作为同步备库。
特殊项*匹配任意备库名称。
没有机制强制备库名称的唯一性。在出现重复的情况下，匹配的备库之一将被认为是较高优先级，不过无法弄清到底是哪一个。
每一个standby_name都应该具有合法 SQL 标识符的形式，除非它是*。如果必要你可以使用双引号。但是注意在比较standby_name和备库应用程序名称时是大小写不敏感的（不管有没有双引号）。
如果这里没有指定同步备库名称，那么同步复制不能被启用并且事务提交将不会等待复制。这是默认的配置。即便当同步复制被启用时，个体事务也可以被配置为不等待复制，做法是将synchronous_commit参数设置为local或off。
这个参数只能在postgresql.conf文件中或通过服务器命令行进行设置。
synchronized_standby_slots (string) #逻辑 WAL 发送进程将等待的流复制备库槽名称的逗号分隔列表。 逻辑 WAL 发送进程仅在指定复制槽确认接收 WAL 后，才会把解码后的更改发送给插件。 这可以确保逻辑复制故障切换槽在相应物理备库接收并刷写这些更改之前，不会消耗这些更改。 如果逻辑复制连接旨在故障切换到物理备库，则该备库的物理复制槽应当列在这里。 请注意，如果synchronized_standby_slots中指定的槽不存在或无效，逻辑复制将不会继续。 此外，使用逻辑故障切换槽的复制管理函数 pg_replication_slot_advance、 pg_logical_slot_get_changes和 pg_logical_slot_peek_changes 将阻塞，直到synchronized_standby_slots中列出的所有物理槽都确认接收到了 WAL。
与synchronized_standby_slots中物理复制槽对应的备库必须配置 sync_replication_slots = true，这样它们才能从主库接收逻辑故障切换槽的更改。
这些设置控制备库接收复制数据时的行为。 它们在主库的值是无关的。
primary_conninfo (string) #指定备库用来连接发送服务器的连接字符串。这个字符串的格式在Section 32.1.1中描述。 如果在这个字符串中有任何选项未被指定，那么将检查相应的环境变量（见Section 32.15）。 如果环境变量也没有被设置，则使用默认值。
连接字符串应当指定发送服务器的主机名（或地址），以及端口号（如果它与备库的默认端口不同）。 还要指定发送服务器上具有适当权限的角色所对应的用户名（见Section 26.2.5.1）。 如果发送端要求密码认证，还需要提供密码。它既可以直接写在 primary_conninfo 字符串中， 也可以写在备库上的独立 ~/.pgpass 文件中（数据库名使用 replication）。
这个参数只能在 postgresql.conf 文件或服务器命令行上设置。 如果在 WAL 接收器进程运行时修改该参数，则会向该进程发送信号使其关闭，并期望它使用新设置重新启动 （除非 primary_conninfo 是空字符串）。 如果服务器没有处于备库模式，则此设置无效。
primary_slot_name (string) #有选择地指定通过流复制连接到发送服务器时使用一个现有的复制槽来控制上游节点上的资源移除（见Section 26.2.6）。 这个参数只能在 postgresql.conf文件或服务器命令行上设置。 如果在 WAL 接收器进程运行时更改此参数，则该进程将发出关机信号，并预期使用新设置重新启动（除非primary_conninfo为空字符串）。 如果没有设置primary_conninfo或服务器没有处于备库模式，则此设置无效。
hot_standby (boolean) #指定在恢复期间，你是否能够连接并运行查询，如Section 26.4中所述。默认值是on。这个参数只能在服务器启动时设置。它只在归档恢复期间或备库模式下才有效。
max_standby_archive_delay (integer) #当热备处于活动状态时，此参数确定备库在取消与即将应用的WAL条目冲突的备库查询之前应等待多长时间，如 Section 26.4.2中所述。 max_standby_archive_delay在从WAL归档中读取WAL数据时适用（因此不是当前的）。 如果未指定单位，则将其视为毫秒。 默认值为30秒。 值为-1允许备库永远等待冲突查询完成。 此参数只能在postgresql.conf文件或服务器命令行中设置。
注意，max_standby_archive_delay与取消之前一个查询能够运行的最长时间不同；它表示应用任何一个 WAL 段数据能够被允许的最长总时间。因此，如果一个查询早于 WAL 段导致了显著的延迟，后续冲突查询将只有更少的时间。
max_standby_streaming_delay (integer) #当热备处于活动状态时，此参数确定备库在取消与即将应用的WAL条目冲突的备库查询之前应等待多长时间，如Section 26.4.2中所述。 max_standby_streaming_delay在通过流复制接收WAL数据时应用。 如果未指定单位，则将其视为毫秒。 默认值为30秒。 值为-1允许备库永远等待冲突查询完成。 此参数只能在postgresql.conf文件或服务器命令行中设置。
注意，max_standby_streaming_delay与取消之前一个查询能够运行的最长时间不同；它表示在从主库接收到 WAL 数据并立刻应用它能够被允许的最长总时间。因此，如果一个查询导致了显著的延迟，后续冲突查询将只有更少的时间，直到备库再次赶上进度。
wal_receiver_create_temp_slot (boolean) #指定在未配置永久复制槽时，WAL 接收器进程是否应在远程实例上创建临时复制槽（使用 primary_slot_name）。 默认为"关闭"。 此参数只能在postgresql.conf文件或服务器命令行中设置。 如果在 WAL 接收器进程运行时更改此参数，则该进程将发出关机的信号，并预期使用新设置重新启动。
wal_receiver_status_interval (integer) #指定在备库上的 WAL 接收者进程向主库或上游备库发送有关复制进度的信息的最小频度，它可以使用pg_stat_replication视图看到。 备库将报告它已经写入的上一个预写式日志位置、它已经刷到磁盘的上一个位置以及它已经应用的最后一个位置。 这个参数的值是报告之间的最大时间量。 每次写入或刷出位置改变时会发送状态更新，或者按这个参数的指定的频度发送，如果设置为非零值。 在其他情况下发送更新时忽略此参数；例如，当现有的WAL处理完成或当synchronous_commit设置为remote_apply时。 因此，应用位置可能比真实位置略微滞后。 如果指定值时没有单位，则以秒为单位。 默认值是 10 秒。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
hot_standby_feedback (boolean) #指定一个热备机是否将会向主库或上游备库发送有关于备库上当前正被执行的查询的反馈。这个参数可以被用来排除由于记录清除导致的查询取消，但是可能导致在主库上用于某些负载的数据库膨胀。反馈消息的发送频度不会高于每个wal_receiver_status_interval周期发送一次。默认值是off。这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
如果使用级联复制，反馈将被向上游传递直到它最后到达主库。备库在接收到反馈之后除了传递给上游不会做任何其他操作。
请注意，如果备库上的时钟被向前或向后调整，反馈消息可能无法按要求的时间间隔发送。 在极端情况下，由于该反馈机制基于时间戳，这可能导致主库长时间面临无法移除死元组的风险。
wal_receiver_timeout (integer) #中止处于非活动状态超过这个时间量的复制链接。这对于正在接收的备库检测主库崩溃或网络断开有用。 如果指定值时没有单位，则以毫秒为单位。默认值是 60 秒。 这个参数只能在postgresql.conf文件中或者服务器命令行中设置。
wal_retrieve_retry_interval (integer) #指定当从任何来源（流复制、本地pg_wal或者 WAL 归档）都得不到 WAL 数据时，备库应该等待多久才去重新尝试获取 WAL 数据。 如果指定值时没有单位，则以毫秒为单位。默认值是 5 秒。 这个参数只能在postgresql.conf文件或者服务器命令行中设置。
这个参数在恢复节点需要控制等待新 WAL 数据可用时长的配置中很有用。例如，在归档恢复中， 降低该参数的值可以让系统在检测到新 WAL 文件时更快作出响应；在 WAL 活动较低的系统上， 增大该值则可以减少访问 WAL 归档所需的请求次数，这在会计量基础设施访问次数的云环境中尤其有用。
在逻辑复制中，该参数还限制失败的复制应用工作者或表同步工作者被重新拉起的频率。
recovery_min_apply_delay (integer) #默认情况下，备库会尽快恢复来自于发送服务器的 WAL 记录。有一份数据的延时拷贝是有用的，它能提供机会纠正数据丢失错误。 这个参数允许你将恢复延迟一段指定的时间量。 例如，如果你设置这个参数为5min，对于一个事务提交，只有当备库上的系统时钟超过主库报告的提交时间至少 5分钟时，备库才会重放该事务。 如果指定值时没有单位，则以毫秒为单位。默认为0，不增加延迟。
有可能服务器之间的复制延迟会超过这个参数的值，在这种情况下则不会增加延迟。 注意延迟是根据主库上写 WAL 的时间戳以及备库上的当前时间来计算。 由于网络延迟或者级联复制配置导致的传输延迟可能会显著地减少实际等待时间。 如果主库和备库上的系统时钟不同步，这会导致恢复比预期的更早应用记录。 但这不是一个主要问题，因为这个参数有用的设置比服务器之间的典型事件偏差要大得多。
只有在事务提交的 WAL 记录上才会发生延迟。其他记录还是会被尽可能快地重放，这不会成为问题，因为 MVCC 可见性规则确保了在对应的提交记录被应用之前它们的效果不会被看到。
一旦恢复中的数据库已经达到一致状态，延迟就会产生，直到备库被提升或者触发。在那之后，备库将会结束恢复并且不再等待。
WAL记录必须保留在备库上，直到准备好应用。因此，较长的延迟将导致WAL文件的积累增加，增加备库的pg_wal目录的磁盘空间需求。
这个参数的目的是和流复制部署一起使用，但是，如果指定了该参数，除了崩溃恢复之外所有的情况下都会遵守它。 使用这个特性也会让hot_standby_feedback被延迟，这可能导致主库的膨胀，两者一起使用时要小心。
当synchronous_commit被设置为remote_apply时，同步复制会受到这个设置的影响，每一个COMMIT都需要等待被应用。
这个参数只能在postgresql.conf文件中或通过服务器命令行进行设置。
sync_replication_slots (boolean) #使物理备库能够从主库同步逻辑故障切换槽，以便逻辑订阅者在故障切换后能够从新的主库恢复复制。
默认情况下该参数被禁用。该参数只能在postgresql.conf文件中或服务器命令行上设置。
createrole_self_grant (string) #如果一个拥有CREATEROLE但不拥有SUPERUSER权限的用户创建了角色，并且此选项被设置为非空值，则新创建的角色将以指定选项授予创建者。 该值必须是set、inherit或它们的逗号分隔列表。默认值为空字符串，这会禁用此功能。
此选项的目的是允许非超级用户的CREATEROLE用户自动继承或自动获得对新创建角色执行SET ROLE的能力。 由于CREATEROLE用户始终会隐式获得其所创建角色的ADMIN OPTION，因此该用户总是可以通过执行GRANT语句达到相同效果，但自动授予在可用性上更方便。 超级用户会自动继承每个角色的权限，并且始终可以切换到任何角色；此设置可用于为CREATEROLE用户提供类似行为。
event_triggers (boolean) #允许临时禁用事件触发器的执行，以便对有故障的事件触发器进行故障排查和修复。 将其设置为false会禁用所有事件触发器；设置为true则允许所有事件触发器触发，这也是默认值。 只有超级用户能更改这个设置。
restrict_nonsystem_relation_kind (string) #设置禁止访问非系统关系的关系类型。该值采用关系类型的逗号分隔列表形式。 目前支持的关系类型是view和foreign-table。
这些设置控制逻辑复制订阅者的行为。它们在发布者上的值与此无关。
注意，配置参数wal_receiver_timeout、wal_receiver_status_interval以及wal_retrieve_retry_interval也影响逻辑复制工作者。
max_active_replication_origins (integer) #指定同时可以跟踪多少个复制源（参见Chapter 48），从而实际上限制了服务器上可以创建多少逻辑复制订阅。 将其设置为低于当前正在跟踪的复制源数量（体现在pg_replication_origin_status中）会阻止服务器启动。 默认值为 10。该参数只能在服务器启动时设置。 max_active_replication_origins至少必须设置为订阅者上要添加的订阅数量，再加上一些用于表同步的预留。
max_logical_replication_workers (integer) #指定逻辑复制工作者的最大数目。这同时包括应用工作者和表同步工作者。
逻辑复制工作者是从max_worker_processes定义的池中取出的。
默认值是4。 这个参数只能在服务器启动时被设置。
max_sync_workers_per_subscription (integer) #每个订阅的同步工作者的最大数目。这个参数控制订阅初始化期间或者新表增加时的初始数据拷贝的并行度。
当前，每个表只能有一个同步工作者。
同步工作者是从max_logical_replication_workers定义的池中取出的。
默认值为2。 这个参数只能在postgresql.conf文件中或服务器命令行上设置。
max_parallel_apply_workers_per_subscription (integer) #每个订阅可使用的并行应用工作进程最大数。该参数控制订阅参数 streaming = parallel时，对正在进行中的事务流进行并行应用的程度。
并行应用工作进程从由max_logical_replication_workers定义的池中获取。
默认值为 2。该参数只能在postgresql.conf文件中或服务器命令行上设置。
如果您发现文档中有不正确的内容、与您使用特定功能的经验不符或需要进一步说明，请使用此表单来报告文档问题。