PostgreSQL 12 preview - Move max_wal_senders out of max_connections for connection slot handling

标簽

PostgreSQL , max_wal_senders , max_connections , sorry, too many clients already

https://github.com/digoal/blog/blob/master/201903/20190309_02.md#%E8%83%8C%E6%99%AF 背景

如果你需要使用PG的流複制，上遊節點的max_wal_senders參數，用來限制這個節點同時最多可以有多少個wal sender程序。

包括邏輯複制、實體複制、pg_basebackup備份等，隻要是使用stream protocol的連接配接，每個連接配接都需要一個wal sender程序，與之建立stream protocol通訊。

在12的版本以前，max_wal_senders是算在max_connections裡面的，也就是說，如果使用者的普通連接配接把資料庫連接配接占光了，流複制連接配接也會不夠用。

12修正了這個問題，max_wal_senders參數獨立控制，不算在max_connections裡面。普通連接配接與流複制連接配接互相不再幹擾。

同時要求standby節點的max_wal_senders參數，必須大于或等于primary（上遊）資料庫的max_wal_senders參數。 與要求standby節點的max_connections參數，必須大于或等于primary（上遊）資料庫的max_connections參數一樣。

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=ea92368cd1da1e290f9ab8efb7f60cb7598fc310

Move max_wal_senders out of max_connections for connection slot handling  
  
Since its introduction, max_wal_senders is counted as part of  
max_connections when it comes to define how many connection slots can be  
used for replication connections with a WAL sender context.  This can  
lead to confusion for some users, as it could be possible to block a  
base backup or replication from happening because other backend sessions  
are already taken for other purposes by an application, and  
superuser-only connection slots are not a correct solution to handle  
that case.  
  
This commit makes max_wal_senders independent of max_connections for its  
handling of PGPROC entries in ProcGlobal, meaning that connection slots  
for WAL senders are handled using their own free queue, like autovacuum  
workers and bgworkers.  
  
One compatibility issue that this change creates is that a standby now  
requires to have a value of max_wal_senders at least equal to its  
primary.  So, if a standby created enforces the value of  
max_wal_senders to be lower than that, then this could break failovers.  
Normally this should not be an issue though, as any settings of a  
standby are inherited from its primary as postgresql.conf gets normally  
copied as part of a base backup, so parameters would be consistent.  
           

https://github.com/digoal/blog/blob/master/201903/20190309_02.md#%E5%8F%82%E8%80%83 參考

《PostgreSQL 拒絕服務DDOS攻擊與防範》

https://github.com/digoal/blog/blob/master/201903/20190309_02.md#%E5%85%8D%E8%B4%B9%E9%A2%86%E5%8F%96%E9%98%BF%E9%87%8C%E4%BA%91rds-postgresql%E5%AE%9E%E4%BE%8Becs%E8%99%9A%E6%8B%9F%E6%9C%BA 免費領取阿裡雲RDS PostgreSQL執行個體、ECS虛拟機