PostgreSQL数据库为了保证在高并发，高连接数情况下某些用户能够正常连接到数据库里，设立了几个用户连接的保留个数。

本文介绍了PostgreSQL16版本前为超级用户保留的连接数（superuser_reserved_connections）以及PostgreSQL16版本新增的为普通用户的保留的连接数（reserved_connections）。

注：复制连接是从为max_wal_senders保留的插槽中提取的，不受max_connections、superuser_reserved_connections以及reserved_connections的限制。

一、最大连接数（max_connections）

PostgreSQL数据库里最大的连接数由max_connections控制。通常情况下，用户可以使用的连接数不可以超过这个设置。

二、为超级用户保留的连接数（superuser_reserved_connections）

最初对于数据库而言，如果会话的释放机制不够合理，没有采用连接池，又恰巧不巧地赶上了业务高峰期，大量并发的情形，是比较棘手的。因为就算我想暂时释放掉部分连接。可能也没有了空余的连接数供我们连接到数据库里进行这番操作。

因此PostgreSQL数据库在7.4版本就为数据库增加了一个superuser_reserved_connections参数，指定为超级用户保留的连接数。这样，当遇到了大量并发连接，甚至不停有新连接产生的时候。我们可以使用超级用户通过这几个保留的连接，进到数据库里，进行一些分析和处理。

superuser_reserved_connections旨在确保即使正常连接数（定义为max_connections- superuser_reserved_connections）耗尽时超级用户也可以连接。

superuser_reserved_connections的默认值为3，默认为超级用户保留3个连接。如果max_connections值为默认的100，“普通”用户可以使用 97 个连接。

因为是保留连接，所以superuser_reserved_connections的值应该小于max_connections的值，不然数据库实例在重启的时候是起不来的。
可以进行如下测试，修改max_connections的连接数，使之少于superuser_reserved_connections，并重启数据库，此时可以发现，数据库启动失败了。并且报了一个提示：

waiting for server to start…postgres: superuser_reserved_connections (3) must be less than max_connections (2)

告诉我们superuser_reserved_connections的值必须比max_connections要小。
在源码postmaster.c的PostmasterMain()函数里也可以看到相关的部分。

三、PostgreSQL16版本新增普通用户的保留连接参数（reserved_connections）

其实对于PostgreSQL16新增的reserved_connections这个参数，随之而来的还有一个pg_use_reserved_connections的角色（详细可见：https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=6e2775e4d4e47775f0d933e4a93c148024a3bc63）。

两个是配套使用的。主要是提供了一种为非超级用户保留连接插槽的方法。

使用reserved_connections这个参数，来确定预定义角色pg_use_reserved_connections成员的保留连接数。

使用测试可见如下：
首先做一些准备工作

postgres=# create user u1 with login password 'Enmo@123';
CREATE ROLE
postgres=# create user u2 with login password 'Enmo@123';
CREATE ROLE
postgres=# grant pg_use_reserved_connections to u1;
GRANT ROLE
postgres=# alter system set max_connections = 5;
ALTER SYSTEM
postgres=# alter system set reserved_connections = 1;
ALTER SYSTEM
postgres=# \q//重启数据库
postgres@ubuntu-linux-22-04-desktop:~$ pg_ctl restart 
waiting for server to shut down.... done
server stopped
waiting for server to start....2023-06-26 13:08:02.479 CST [729348] LOG:  starting PostgreSQL 16beta1 on aarch64-unknown-linux-gnu, compiled by gcc (Ubuntu 11.3.0-1ubuntu1~22.04.1) 11.3.0, 64-bit
2023-06-26 13:08:02.479 CST [729348] LOG:  listening on IPv4 address "127.0.0.1", port 6432
2023-06-26 13:08:02.480 CST [729348] LOG:  listening on Unix socket "/tmp/.s.PGSQL.6432"
2023-06-26 13:08:02.487 CST [729351] LOG:  database system was shut down at 2023-06-26 13:08:02 CST
2023-06-26 13:08:02.491 CST [729348] LOG:  database system is ready to accept connectionsdone
server startedpostgres@ubuntu-linux-22-04-desktop:~$ psql
psql (16beta1)
Type "help" for help.postgres=# \dconfig *connections*List of configuration parametersParameter            | Value 
--------------------------------+-------log_connections                | offlog_disconnections             | offmax_connections                | 5reserved_connections           | 1superuser_reserved_connections | 3
(5 rows)

然后使用如下方式进行测试，首先使用一个没有授予pg_use_reserved_connections角色的普通用户进行测试

图中这个现象是符合预期的，因为max_connections的5个连接，去掉给超级用户预留的3个连接和给u1保留的一个连接外，只剩了一个连接，只允许其他的普通用户连接一个到数据库里。正如提示的：

remaining connection slots are reserved for roles with privileges of the “pg_use_reserved_connections” role
（剩余的连接槽是为具有“pg_use_reserved_connectionships”角色权限的角色保留的）

断开所有的连接，然后用授予了pg_use_reserved_connections角色的u1用户连接又会怎样呢？

这个现象也是符合预期的，最开始第一个u1用户到数据库里的连接使用的是非参数保留的连接槽，等到普通的连接都用完了，就用到了参数为授予了该角色的用户保留的连接槽，因此，第二个也能连接上，但是当为普通用户保留的连接槽也用光了，则无法获取到可用的连接槽，就不能够连接到数据库里。正如提示的：

remaining connection slots are reserved for roles with SUPERUSER
（剩余的连接插槽是为具有SUPERUSER的角色保留的）

此外通过新版本的源码我们可以看到，新增的reserved_connections和原本的superuser_reserved_connections一样被加入到了数据库启动的检查里。如果两个参数的值之和大于或者等于最大连接数，那么，数据库实例也是起不来的，就会调用ExitPostmaster函数，关闭进程。因为本身要保留的连接个数已经设定了，但是最大连接数不能保证基本的预留个数，这明显是不合理的，因此，数据库不允许这样的实例启动。

乍一看这个改动似乎很鸡肋，因为正常情况下，一堆业务连接，他们应该是等价的。但是，结合以往的经验，细想一下，就知道了这个改动的意义。就算连接数被业务占满了，也要保证备份和监视工具能够连接到数据库。这样对于数据库的数据以及问题可追踪性，可观测性至关重要的。

以往为了在连接数占满的情况下，监控依旧能采集到信息，部分非生产业务，在安全部分不做严格限制的情况下，或许会为监控用户授予superuser的角色，来使监控可以持续地采集到信息。但实际上给监控的用户这么大权限，是很不安全的，因此，PostgreSQL16新版本的这个改动，让我们即可以为监控或者备份等保留连接槽，也对于安全方面做了保证。

除此之外，经过测试，发现超级用户可以使用所有的连接，包含PostgreSQL16新版本新增的为普通用户保留的连接。

而为了验证当超级用户用完了普通连接后，下一步使用的连接是为普通用户预先保留的还是为超级用户预先保留的连接槽，我进行了如下的测试，因为最大连接数设置的5，超级用户的保留连接设置的3，为普通用户u1保留的连接槽是1，那么当我用超级用户预先创建两个连接，第三个使用u1用户去创建连接，如果能够创建成功，说明第三次使用的是预先为u1保留的连接槽，那么超级用户的第二个获取的连接槽是预先为超户保留的，如果获取失败，则超级用户的第二个获取的连接槽是预先为普通用户保留的。