1.备库不同步主库修改的参数
流复制的主备关系：
8个参数可以主备同步：max_connections、max_worker_processes、max_wal_senders、max_prepared_xacts、wal_level、wal_log_hints、track_commit_timestamp
这些GUC参数对于备库来说，至关重要，所以也全都是必须要重启生效 (postmaster)。
max_connections 这类参数要求备库上的这些共享内存结构必须不小于主库上的结构，以确保备库在恢复期间不会耗尽共享内存。
tips:
max_connections ，当比备库小的时候，流复制会暂停，在 14 以前的版本，重启主库，备库会挂掉，因为在 replay 这一条 record 的时候检测到了错误，在 14 进行了优化，仅仅是暂停流复制 (sent_lsn 停滞) 。
2.备库上max_connections比主库大
FATAL: recovery aborted because of insufficient parameter settings
DETAIL: max_connections = 99 is a lower setting than on the primary server, where its value was 100.
max_connections
max_wal_senders
max_worker_processes
max_prepared_transactions
max_locks_per_transaction
这五个参数都是postmaster级别，调整后均需要重启才能生效.
举例1:子事物同步过程中，备库要有一定的数据结构来记录标记点；
举例2:max_locks_per_transaction,shared buffers中用于存放锁的buffer是固定大小的（总共max_locks_per_transaction * max_connections个）,超过了就会提示out of shared memory。假如，主库的max_connections是100，max_locks_per_transaction是1的话，那么总共锁的数量就是100。一旦备库的max_connections值比主库小，那么备库上锁的区域就不够了，更不用说这个时候备库万一还存在查询等活动，那么很容易就会out of shared memory，复制就中断了。
V14优化：
在14的版本里，针对这种情况还做了一个优化，当主库上修改了上面五个参数，并且比备库上的值更小时，不会再导致备库宕库了，而是改成暂停恢复，当备库参数修改为大于等于主库后便会继续自动恢复。
流复制模式下，不管是procarray还是快照都不能直接与备库共享，备库是从WAL日志中接收并回放所需的所有数据，因此势必会多一些额外的数据结构来做这些工作，为了不让共享内存溢出，便有了这个限制。
另外在14以后的版本，流复制假如遇到延迟了还要考虑到参数的影响，虽然这个场景不容易遇到。
3.multiple postmaster
生产案例 | multiple postmaster
https://mp.weixin.qq.com/s/9_FGJ4ctNlOGAtXc5WsY5A
当有大量连接的时候，PostgreSQL疲于奔命，大量fork连接，连接还处于一个中间态的时候，即还没有脱离postmaster的时候。
此时要关注机器负载和连接数，密码穷举攻击
4.查看pg的参数等级
select distinct context from pg_settings;
context
-------------------
postmaster
superuser-backend
user
internal
backend
sighup
superuser
select * from pg_settings where name like '%max_conn%';
-[ RECORD 1 ]---+-----------------------------------------------------
name | max_connections
setting | 600
unit |
category | Connections and Authentication / Connection Settings
short_desc | Sets the maximum number of concurrent connections.
extra_desc |
context | postmaster
vartype | integer
source | configuration file
min_val | 1
max_val | 262143
enumvals |
boot_val | 100
reset_val | 600
sourcefile | /app1/pgsql_18801/data/postgresql.conf
sourceline | 802
pending_restart | f
internal 这些参数不能直接修改，他们反应了内部确定的值，其中一些可以通过重新initdb来修改，例如block_size，另一些则不能修改，例如server_version(数据库版本)
postmaster 这些参数只能在数据库服务启动时应用，因此修改这类参数需要重新启动数据库
sighup 应用这些配置需要向postmaster发送sighup信号，使其重新读取配置文件，所以使其生效需要执行pg_ctl reload或者pg_reload_conf()，并且postmaster还将sighup发送到子进程，让所有子进程都获取参数的新值。
superuser-backend 1.必须是superuser或适当权限才能修改该参数
2.在配置文件中修改后，需要发送SIGHUP使其生效
3.当前会话无法使新参数生效，无法通过set在当前会话中配置新值，只能影响后续启动的会话，
典型参数是log_connections和log_disconnections
backend 1. 在配置文件中修改后，需要发送SIGHUP使其生效
2. 当前会话无法使新参数生效，无法通过set在当前会话中配置新值，只能影响后续启动的会话
superuser 必须是superuser或适当权限才能修改该参数
user 1. 普通用户可执行
2. 可按照用户/库进行单独配置
声明：本文的一些灵感来自阅读xiongcc老师的公众号文章～学习cc老师，一起为爱发电
