Postgres-XL 10 使用介绍（三）

##### systemd RemoveIPC

##### Resource Limits

##### Linux Memory Overcommit

##### Linux Huge Pages

像PostgreSQL一样，使用大的连续页面可以减少使用大块连续内存时的开销，尤其是当使用大值的shared_buffers时。 要在PostgreSQL中使用此功能，您需要具有`CONFIG_HUGETLBFS = y`和`CONFIG_HUGETLB_PAGE = y`的内核。 您还必须调整内核设置`vm.nr_hugepages`。 要估计所需的大页面数，请在未启用大页面的情况下启动PostgreSQL，并使用/ proc文件系统检查邮局局长的VmPeak值以及系统的大页面大小。 可能看起来像：

```shell
$ head -1 $PGDATA/postmaster.pid
4170
$ grep ^VmPeak /proc/4170/status
VmPeak:  6490428 kB
$ grep ^Hugepagesize /proc/meminfo
Hugepagesize:       2048 kB
```

6490428/2048大约为3169.154，因此在此示例中，我们至少需要3170个大页面，可以通过以下方式设置：

```shell
$ sysctl -w vm.nr_hugepages=3170
```

如果计算机上的其他程序也需要大页面，则较大的设置将是适当的。 不要忘记将此设置添加到`/etc/sysctl.conf`中，以便在重新启动后重新应用该设置。

有时内核无法立即分配所需数量的大页面，因此可能有必要重复该命令或重新引导。 （重新启动后，应立即将机器的大部分内存转换成大页。）要验证大页分配情况，请使用：

```shell
$ grep Huge /proc/meminfo
```

也可能需要通过sysctl设置vm.hugetlb_shm_group来授予数据库服务器的操作系统用户使用大页面的权限，和/或使用ulimit -l授予锁定内存的权限。

PostgreSQL中大页面的默认行为是在可能的情况下使用它们，而在失败时退回到普通页面。 要强制使用大页面，可以在postgresql.conf中将huge_pages设置为on。 请注意，如果没有足够大的页面，使用此设置的PostgreSQL将无法启动。

有关Linux大页面功能的详细说明，请访问https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt。

#### Shutting Down the Server

本节介绍如何关闭每个协调器和数据节点。 请注意，您应该先关闭Coordinator，然后再关闭Datanodes，GTM-Proxy和GTM。

##### Shutting Down Coordinators and Datanodes

有几种关闭数据库服务器的方法。 您可以通过向主postgres进程发送不同的信号来控制关闭的类型。

SIGTERM

这是智能关机模式。 收到SIGTERM后，服务器将禁止新连接，但允许现有会话正常结束其工作。 仅在所有会话终止后，它才会关闭。 如果服务器处于联机备份模式，它将另外等待，直到联机备份模式不再处于活动状态。 在备份模式处于活动状态时，仍将允许新连接，但仅允许与超级用户建立连接（此例外允许超级用户进行连接以终止在线备份模式）。 如果在请求智能关闭时服务器处于恢复状态，则只有在所有常规会话都终止之后，恢复和流式复制才会停止。

SIGINT

这是快速关机模式。 服务器禁止新连接，并发送所有现有服务器进程SIGTERM，这将导致它们中止其当前事务并立即退出。 然后，它等待所有服务器进程退出并最终关闭。 如果服务器处于联机备份模式，则备份模式将终止，从而使备份无用。

SIGQUIT

这是立即关闭模式。 服务器将SIGQUIT发送给所有子进程，并等待它们终止。 如果没有在5秒钟内终止，则会向他们发送SIGKILL。 所有子进程都退出后，主服务器进程将立即退出，而不进行正常的数据库关闭处理。 下次启动时，这将导致恢复（通过重播WAL日志）。 仅在紧急情况下才建议这样做。

pg_ctl程序提供了一个方便的接口，用于发送这些信号以关闭服务器。 或者，您可以在非Windows系统上使用kill直接发送信号。 可以使用ps程序或从数据目录中的文件postmaster.pid中找到postgres进程的PID。 例如，要进行快速关机：

```shell
kill -INT `head -1 /usr/local/pgsql/data/postmaster.pid`
```

最好不要使用SIGKILL关闭服务器。 这样做将阻止服务器释放共享内存和信号量，然后可能必须先手动完成这些操作，然后才能启动新服务器。 此外，SIGKILL会杀死postgres进程而不让其将信号中继到其子进程，因此也有必要手动杀死各个子进程。

要在允许其他会话继续进行的同时终止单个会话，请使用pg_terminate_backend（）（请参见表9.78）或向与该会话关联的子进程发送SIGTERM信号。

##### Shutting Down GTM-Proxies

您可以通过向每个GTM代理进程发送SIGKILL，SIGTERM，SIGQUIT，SIGINT或SIGHUP来关闭GTM代理。 GTM代理进程号记录在每个GTM代理工作目录中的文件gtm_proxy.pid中。

##### Shutting Down GTM

您可以通过将SIGKILL，SIGTERM，SIGQUIT，SIGINT或SIGHUP发送到GTM进程来关闭GTM。 GTM进程号记录在GTM工作目录中的文件gtm.pid中。

#### Upgrading a PostgreSQL Cluster

本节讨论如何将数据库数据从一个PostgreSQL版本升级到一个新版本。
由于Postgres-XL的Coordinators和Datanode本质上是PostgreSQL服务器，因此您可以按照以下描述的步骤升级它们。 请注意，您应该手动执行此操作。

当前的PostgreSQL版本号由主版本号和次版本号组成。 例如，在版本号10.1中，10是主要版本号，1是次要版本号，这意味着这将是主要版本10的第一个次要版本。对于PostgreSQL 10.0之前的版本，版本号包括 三个数字，例如9.5.3。 在这些情况下，主要版本由版本号的前两位数字组（例如9.5）组成，次要版本是第三个数字组（例如3），这意味着这将是主要版本9.5的第三个次要版本。

次要版本永远不会更改内部存储格式，并且始终与相同主版本号的早期和较晚次要版本兼容。 例如，版本10.1与版本10.0和版本10.6兼容。 类似地，例如，9.5.3与9.5.0、9.5.1和9.5.6兼容。 要在兼容版本之间进行更新，只需在服务器关闭时替换可执行文件，然后重新启动服务器即可。 数据目录保持不变-较小的升级就这么简单。

对于PostgreSQL的主要发行版，内部数据存储格式可能会发生更改，从而使升级变得复杂。 将数据移动到新的主要版本的传统方法是转储并重新加载数据库，尽管这可能很慢。 更快的方法是pg_upgrade。 复制方法也可用，如下所述。

新的主要版本通常还会引入一些用户可见的不兼容性，因此可能需要更改应用程序编程。 所有用户可见的更改都在发行说明中列出（附录E）； 请特别注意标有“迁移”的部分。 如果要跨多个主要版本进行升级，请确保阅读每个中间版本的发行说明。

谨慎的用户会希望在完全切换之前在新版本上测试其客户端应用程序； 因此，最好同时设置新旧版本的安装。 在测试PostgreSQL重大升级时，请考虑以下类别的可能更改：

​        **Postgres-XL中未测试对pg_upgrade的支持。 建议用户使用其他方法升级到Postgres-XL的下一个主要版本。**

Administration

在每个主要版本中，管理员可用来监视和控制服务器的功能经常更改和改进。

SQL

通常，这包括新的SQL命令功能，并且不包括行为更改，除非发行说明中特别提及。

Library API

通常，像libpq这样的库只会添加新功能，除非发行说明中另有提及。

System Catalogs

系统目录更改通常仅影响数据库管理工具。

Server C-language API

这涉及使用C编程语言编写的后端函数API的更改。 此类更改会影响引用服务器内部后端功能的代码。

##### Upgrading Data via pg_dumpall

一种升级方法是从一个主要PostgreSQL版本中转储数据，然后将其重新加载到另一个主要版本中-为此，您必须使用pg_dumpall之类的逻辑备份工具。 文件系统级备份方法将不起作用。 （有适当的检查可以防止您将数据目录与PostgreSQL的不兼容版本一起使用，因此，尝试在数据目录上启动错误的服务器版本不会造成很大的伤害。）

建议您使用更新版本的PostgreSQL中的pg_dump和pg_dumpall程序，以利用这些程序中可能进行的增强。 当前版本的转储程序可以从追溯7的服务器版本读取数据.

这些说明假定您现有的安装位于/ usr / local / pgsql目录下，并且数据区域位于/ usr / local / pgsql / data中。 适当替换您的路径。

1. 如果要进行备份，请确保未更新数据库。 这不会影响备份的完整性，但是更改后的数据当然不会包括在内。 如有必要，请编辑文件/usr/local/pgsql/data/pg_hba.conf（或等效文件）中的权限，以禁止除您之外的任何人进行访问。 有关访问控制的更多信息，请参见第20章。

   要备份数据库安装，请键入：

   ```shell
   pg_dumpall > outputfile
   ```

   要进行备份，可以使用当前正在运行的版本中的pg_dumpall命令。 有关更多详细信息，请参见第25.1.2节。 为了获得最佳结果，请尝试使用PostgreSQL 10r1.1中的pg_dumpall命令，因为该版本包含错误修复和对旧版本的改进。 尽管由于尚未安装新版本，此建议似乎有些特殊，但如果您打算与旧版本并行安装新版本，建议您遵循该建议。 在这种情况下，您可以正常完成安装并稍后传输数据。 这也将减少停机时间。

2. 关闭旧服务器：

   ```shell
   pg_ctl stop
   ```

   在启动时已启动PostgreSQL的系统上，可能会有一个启动文件来完成相同的任务。 例如，在Red Hat Linux系统上，您可能会发现这可行：

   ```shell
   /etc/rc.d/init.d/postgresql stop
   ```

   有关启动和停止服务器的详细信息，请参见第18章。

3. 如果要从备份还原，请重新命名或删除旧的安装目录（如果它不是特定于版本的）。 最好重命名目录，而不是删除目录，以防万一您需要恢复到该目录。 请记住，目录可能会占用大量磁盘空间。 要重命名目录，请使用如下命令：

   ```shell
   mv /usr/local/pgsql /usr/local/pgsql.old
   ```

   （请确保将目录作为一个整体移动，以便相对路径保持不变。）

4. 如第16.4节所述安装新版本的PostgreSQL。

5. 如果需要，创建一个新的数据库集群。 请记住，登录到特殊数据库用户帐户（如果要进行升级，则已经拥有）时必须执行这些命令。

   ```shell
   /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
   ```

6. 恢复先前的pg_hba.conf和任何postgresql.conf修改。

7. 再次使用特殊的数据库用户帐户启动数据库服务器：

   ```shell
   /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data
   ```

8. 最后，使用以下方法从备份中还原数据：

   ```shell
   /usr/local/pgsql/bin/psql -d postgres -f outputfile
   ```

   使用新的psql.

   通过将新服务器安装在不同目录中，并在不同端口上并行运行旧服务器和新服务器，可以使停机时间最少。 然后，您可以使用类似：

   ```shell
   pg_dumpall -p 5432 | psql -d postgres -p 5433
   ```

##### Upgrading Data via pg_upgrade

pg_upgrade模块允许将安装从一个主要PostgreSQL版本就地迁移到另一个主要PostgreSQL版本。 升级可以在几分钟内完成，尤其是使用--link模式时。 它需要类似于上述pg_dumpall的步骤，例如 启动/停止服务器，运行initdb。 pg_upgrade文档概述了必要的步骤。

##### Upgrading Data via Replication

也可以使用某些复制方法（例如Slony）来创建具有更新版本PostgreSQL的备用服务器。 这是可能的，因为Slony支持在PostgreSQL的不同主要版本之间进行复制。 备用计算机可以在同一台计算机上，也可以在另一台计算机上。 一旦它与主服务器同步（运行旧版本的PostgreSQL），您就可以切换主服务器并将备用服务器作为主服务器，并关闭旧数据库实例。 这种切换只会导致升级停机几秒钟。

#### Preventing Server Spoofing

#### Encryption Options

#### Secure TCP/IP Connections with SSL

#### Secure TCP/IP Connections With SSH Tunnels

#### Registering Event Log on Windows

### Coordinator and Datanode Configuration

#### Setting Parameters

##### Paramter Names and Values

所有的参数都是不区分大小写的.每个参数值都是如下的五种类型之一:boolean,string,integer,floating point,enumerated(enum:枚举).对应类型的语法格式如下:

- Boolean: boolean可以为如下值:on ,off,true,false,yes,no ,1,0 并且都不区分大小写及有特定前缀说法.
- String:通常，将值括在单引号中，将值内的任何单引号加倍。 但是，如果值是一个简单数字或标识符，通常可以省略引号。
- Numeric(整数及浮点类型):小数点仅允许用于浮点参数。 不要使用千位分隔符。 不需要引号。
- Numeric with Unit(带单位的数字):一些数字参数具有隐式单位，因为它们描述了内存或时间量。 单位可以是千字节，块（通常为八千字节），毫秒，秒或分钟。 这些设置之一的未经修饰的数值将使用该设置的默认单位，可以从`pg_settings.unit`中学习。 为了方便起见，可以使用明确指定的单位（例如，时间值“ 120 ms”）进行设置，然后将其转换为参数的实际单位。 请注意，该值必须作为字符串（带引号）写入才能使用此功能。 单位名称区分大小写，数值和单位之间可以有空格。
  有效的内存单位是kB（千字节），MB（兆字节），GB（千兆字节）和TB（兆字节）。 存储单元的乘数为1024，而不是1000。
  有效时间单位为ms（毫秒），s（秒），min（分钟），h（小时）和d（天）。
- Enumerated:枚举类型的参数与字符串参数的写入方式相同，但仅限于具有一组有限的值。 可以从`pg_settings.enumvals`中找到该参数允许的值。 枚举参数值不区分大小写。

##### Parameter Interaction via the Configuration File

最常见的修改参数的方式是进行配置文件`postgres.conf`的配置,通常而言这个配置文件是保存在数据目录下的.当数据库集群初始化话时,就提供默认的配置文件.例如配置文件格式如下:

```properties
# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
```

每行指定一个参数。 名称和值之间的等号是可选的。 空格无关紧要（带引号的参数值中除外），并且空行将被忽略。 井号（＃）将行的其余部分指定为注释。 非简单标识符或数字的参数值必须用单引号引起来。 要将单引号嵌入参数值中，请写两个引号（首选）或反斜杠引号。

以这种方式设置的参数为群集提供默认值。 除非被覆盖，否则激活的Session看到的设置将是这些值。 以下各节介绍了管理员或用户可以覆盖这些默认设置的方式。

每当主服务器进程收到SIGHUP信号时，都会重新读取配置文件,通过从命令行运行`pg_ctl reload`或调用SQL函数`pg_reload_conf()`，最方便发送此信号。主Coordinator / Datanode进程还将此信号传播到所有当前正在运行的服务器进程，以便现有会话也采用新值（这将在它们完成任何当前正在执行的客户端命令之后发生）。 或者，您可以将信号直接发送到单个服务器进程。 某些参数只能在服务器启动时设置。 在重新启动服务器之前，将忽略对配置文件中条目的任何更改。 在SIGHUP处理期间，同样会忽略（但会记录）配置文件中无效的参数设置。

除postgresql.conf外，PostgreSQL数据目录还包含一个文件postgresql.auto.conf，该文件的格式与postgresql.conf相同，但切勿手动对其进行编辑。 该文件包含通过ALTER SYSTEM命令提供的设置。 只要有postgresql.conf，就会自动读取此文件，并且其设置以相同的方式生效。 postgresql.auto.conf中的设置将覆盖postgresql.conf中的设置。

系统视图`pg_file_settings`有助于预先测试对配置文件的更改，或者如果SIGHUP信号未达到预期效果，则有助于诊断问题。

##### Parameter Interaction via SQL

PostgreSQL提供了三个SQL命令来建立默认配置。 已经提到的ALTER SYSTEM命令提供了一种可通过SQL访问的方式来更改全局默认值。 它在功能上等同于编辑postgresql.conf。 另外，有两个命令允许按数据库或角色设置默认值：

- ALTER DATABASE命令允许在每个数据库的基础上覆盖全局设置。
- ALTER ROLE命令允许全局和每个数据库设置都被用户特定的值覆盖。

用ALTER DATABASE和ALTER ROLE设置的值仅在启动新的数据库会话时适用。 它们会覆盖从配置文件或服务器命令行获取的值，并构成其余会话的默认值。 请注意，服务器启动后无法更改某些设置，因此无法使用这些命令（或下面列出的命令）进行设置。

一旦客户端与数据库建立连接后,PostgreSQL提供2个额外的SQL命令(其实就是函数)来改变当前session的配置:

- SHOW命令允许检查所有参数的当前值。 相应的功能是current_setting（setting_name text）。
- SET命令允许修改可以在会话中本地设置的那些参数的当前值。 它对其他会话没有影响。 对应的函数是set_config（setting_name，new_value，is_local）。

此外，系统视图pg_settings可用于查看和更改local session值:

- 查询此视图类似于使用SHOW ALL，但提供更多详细信息。 它也更加灵活，因为可以指定过滤条件或加入其他关系。

- 在此视图上使用UPDATE（特别是更新设置列）等效于发出SET命令。 例如，相当于:

  ```sql
  SET configuration_parameter TO DEFAULT;
  
  UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';
  ```

##### Parameter Interaction via the Shell

除了设置全局默认值或在数据库或角色级别附加替代，您还可以通过shell程序将设置传递给PostgreSQL。 服务器和libpq客户端库都通过shell接受参数值。

- 在服务启动的时候,可以在postgres 命令通过-c 配置命令行参数,例如:

  ```shell
  postgres --coordinator -c log_connections=yes -c log_destination='syslog'
  ```

  通过这种方式提供的设置将覆盖通过postgresql.conf或ALTER SYSTEM进行的设置，因此，如果不重新启动服务器，则无法全局更改它们。

- 通过libpq启动客户端会话时，可以使用PGOPTIONS环境变量指定参数设置。 以这种方式建立的设置构成会话生命周期的默认值，但不影响其他会话。 由于历史原因，PGOPTIONS的格式类似于启动postgres命令时使用的格式； 具体来说，必须指定-c标志。 例如，

  ```shell
  env PGOPTIONS="-c geqo=off -c statement_timeout=5min" psql
  ```

  其他客户端和库可能会通过外壳或其他方式提供自己的机制，这些机制使用户无需直接使用SQL命令即可更改会话设置。

##### Managing Configuration File Contents

PostgreSQL提供了几种功能，可以将复杂的postgresql.conf文件分解为子文件。 当使用相关但不相同的配置管理多台服务器时，这些功能特别有用。

除了单独的参数设置之外，postgresql.conf文件还可以包含include伪指令，该伪指令指定另一个要读取和处理的文件，就像此时已将其插入配置文件一样。 此功能允许将配置文件分为物理上独立的部分。 包含指令看起来就像:

```properties
include 'filename'
```

果文件名不是绝对路径，则将其视为包含引用配置文件的目录的相对路径。 内部支持嵌套

还有一个include_if_exists指令，其作用与include指令相同，但所引用的文件不存在或无法读取时除外。 常规include将认为这是错误情况，但是include_if_exists仅记录一条消息并继续处理引用配置文件。

postgresql.conf文件还可以包含include_dir指令，该指令指定要包含的配置文件的整个目录。 这些看起来像

```properties
include_dir 'directory'
```

非绝对目录名被视为相对于包含引用配置文件的目录。 在指定目录中，仅包含名称后缀为.conf的非目录文件。 以开头的文件名。 字符也将被忽略，以防止出错，因为此类文件在某些平台上是隐藏的。 包含目录中的多个文件按文件名顺序处理（根据C语言环境规则，即字母前的数字和小写字母前的大写字母）。

包含文件或目录可用于在逻辑上分隔数据库配置的各个部分，而不是具有单个大型postgresql.conf文件。 考虑一家拥有两个数据库服务器的公司，每个服务器具有不同的内存量。 对于诸如日志之类的东西，配置中可能都有共享的元素。 但是服务器上与内存相关的参数在这两者之间会有所不同。 而且可能还会有特定于服务器的自定义项。 解决这种情况的一种方法是将站点的自定义配置更改分为三个文件。 您可以将其添加到postgresql.conf文件的末尾以包括它们：

```properties
include 'shared.conf'
include 'memory.conf'
include 'server.conf'
```

所有系统都将具有相同的shared.conf。 具有特定内存量的每个服务器都可以共享相同的memory.conf； 对于所有具有8GB RAM的服务器，您可能会有一个服务器；对于具有16GB的服务器，可能会有一个服务器。 最后，server.conf中可能包含真正的服务器特定的配置信息。

另一种可能性是创建一个配置文件目录，并将此信息放入那里的文件中。 例如，可以在postgresql.conf的末尾引用conf.d目录：

```
include_dir 'conf.d'
```

然后你可以将相关文件放在conf.d目录下,如

00shared.conf
01memory.conf
02server.conf

该命名约定确定了加载这些文件的明确顺序。 这很重要，因为仅使用服务器读取配置文件时特定参数遇到的最后一个设置。 在此示例中，在conf.d / 02server.conf中设置的内容将覆盖在conf.d / 01memory.conf中设置的值。

您可以改用这种方法来描述性地命名文件：

00shared.conf
01memory-8GB.conf
02server-foo.conf

这种安排为每个配置文件变体提供了唯一的名称。 当多个服务器的配置都存储在一个位置（例如版本控制存储库）中时，这可以帮助消除歧义。 （在版本控制下存储数据库配置文件是要考虑的另一种好习惯。）

#### File Locations

除了已经提到的postgresql.conf文件，PostgreSQL还使用其他两个手动编辑的配置文件来控制客户端身份验证（它们的使用将在第20章中讨论）。 默认情况下，所有三个配置文件都存储在数据库集群的数据目录中。 本节中描述的参数允许将配置文件放置在其他位置。 （这样做可以简化管理。尤其是，将配置文件分开保存时，通常更容易确保正确备份它们。）

data_directory（字符串）
指定用于数据存储的目录。 该参数只能在服务器启动时设置。
config_file（字符串）
指定主服务器配置文件（通常称为postgresql.conf）。 该参数只能在postgres命令行上设置。
hba_file（字符串）
指定用于基于主机的身份验证的配置文件（通常称为pg_hba.conf）。 该参数只能在服务器启动时设置。
ident_file（字符串）
指定用于用户名映射的配置文件（通常称为pg_ident.conf）。 该参数只能在服务器启动时设置。 另见20.2节。
external_pid_file（字符串）
指定服务器应创建供服务器管理程序使用的其他进程ID（PID）文件的名称。 该参数只能在服务器启动时设置。

在默认安装中，以上参数均未明确设置。 而是通过-D命令行选项或PGDATA环境变量指定数据目录，并且所有配置文件都在数据目录中找到。

如果希望将配置文件保留在数据目录之外的其他位置，则postgres -D命令行选项或PGDATA环境变量必须指向包含配置文件的目录，并且必须在postgresql.conf中设置data_directory参数（或在 命令行）以显示数据目录的实际位置。 请注意，data_directory在数据目录的位置上覆盖了-D和PGDATA，但在配置文件的位置上未覆盖。

如果需要，可以使用参数config_file，hba_file和/或ident_file分别指定配置文件的名称和位置。 config_file只能在postgres命令行上指定，而其他可以在主配置文件中设置。 如果显式设置了所有三个参数以及data_directory，则无需指定-D或PGDATA。

设置这些参数中的任何一个时，将相对于启动postgres的目录解释相对路径。

#### Connections and Authentication

##### Connection Settings

`listen_addresses` (`string`)

​        指定服务器用于侦听来自客户端应用程序的连接的TCP / IP地址。 该值采用主机名和/或数字IP地址的逗号分隔列表的形式。 特殊条目*对应于所有可用的IP接口。 条目0.0.0.0允许侦听所有IPv4地址，而::允许侦听所有IPv6地址。 如果列表为空，则服务器根本不监听任何IP接口，在这种情况下，只能使用Unix域套接字连接。 默认值为localhost，它仅允许建立本地TCP / IP“环回”连接。 客户端身份验证（第20章）允许对谁可以访问服务器进行细粒度控制，而listen_addresses控制哪些接口接受连接尝试，这可以帮助防止在不安全的网络接口上重复出现恶意连接请求。 该参数只能在服务器启动时设置。

`port` (`integer`)

​    服务器监听的TCP端口； 默认为5432。 请注意，服务器侦听的所有IP地址都使用相同的端口号。 该参数只能在服务器启动时设置。

`max_connections` (`integer`)

​    确定与数据库服务器的最大并发连接数。 默认值通常为100个连接，但是如果您的内核设置不支持该连接，则该值可能会更少（由initdb确定）。 该参数只能在服务器启动时设置。

​    运行备用服务器时，必须将此参数设置为与主服务器上相同或更高的值。 否则，备用服务器将不允许查询。

​    对于协调器，此参数确定每个协调器可以接受多少个连接。

​    对于数据节点，与每个数据节点的连接数可能会变为max_connections乘以协调器数

`superuser_reserved_connections` (`integer`)

​    确定为PostgreSQL超级用户保留用于连接的连接保留的数量。 最多max_connections个连接可以同时处于活动状态。 每当活动的并发连接数至少为max_connections减去superuser_reserved_connections时，仅超级用户将接受新连接，而新的复制连接将不被接受

默认值为三个连接。 该值必须小于max_connections的值。 该参数只能在服务器启动时设置。

`unix_socket_directories` (`string`)

​    指定服务器要在其上侦听来自客户端应用程序的连接的Unix域套接字的目录。 可以通过列出用逗号分隔的多个目录来创建多个套接字。 条目之间的空格将被忽略； 如果您需要在名称中包含空格或逗号，请在目录名称两边加上双引号。 空值表示不侦听任何Unix域套接字，在这种情况下，只能使用TCP / IP套接字连接到服务器。 默认值通常为/ tmp，但可以在构建时更改。 该参数只能在服务器启动时设置。

除了名为.s.PGSQL.nnnn的套接字文件本身（其中nnnn是服务器的端口号）之外，还将在每个unix_socket_directories目录中创建一个名为.s.PGSQL.nnnn.lock的普通文件。 都不应该手动删除这两个文件。

在没有Unix域套接字的Windows上，此参数无关。

`unix_socket_group` (`string`)

​    设置Unix域套接字的所属组。 （套接字的拥有者始终是启动服务器的用户。）与参数unix_socket_permissions结合使用，可以将其用作Unix域连接的附加访问控制机制。 默认情况下，这是空字符串，它使用服务器用户的默认组。 该参数只能在服务器启动时设置。
在没有Unix域套接字的Windows上，此参数无关。

`unix_socket_permissions` (`integer`)

​    设置Unix域套接字的访问权限。 Unix域套接字使用通常的Unix文件系统权限集。参数值应为chmod和umask系统调用接受的格式指定的数字模式。 （要使用常规的八进制格式，数字必须以0（零）开头。）
默认权限为0777，表示任何人都可以连接。合理的选择是0770（仅用户和组，另请参见unix_socket_group）和0700（仅用户）。 （请注意，对于Unix域套接字，仅写权限很重要，因此设置或撤消读或执行权限毫无意义。）
这种访问控制机制独立于第20章中描述的机制。
该参数只能在服务器启动时设置。
此参数与完全忽略套接字许可权的系统（尤其是Solaris 10或更高版本的Solaris）无关。在那里，通过将unix_socket_directories指向具有仅限于所需受众的搜索权限的目录，可以达到类似的效果。在没有Unix域套接字的Windows上，该参数也无关紧要。

`bonjour_name` (`string`)

​    通过Bonjour启用服务器。 默认为关闭。 该参数只能在服务器启动时设置。

`bonjour_name` (`string`)

​    指定Bonjour服务名称。 如果此参数设置为空字符串“（默认），则使用计算机名。 如果服务器不是在Bonjour支持下编译的，则忽略此参数。 该参数只能在服务器启动时设置。

`tcp_keepalives_idle` (`integer`)

​    指定不活动的秒数，在此之后，TCP应该向客户端发送保持活动消息。 值0使用系统默认值。 仅在支持TCP_KEEPIDLE或等效套接字选项的系统以及Windows上才支持此参数。 在其他系统上，它必须为零。 在通过Unix域套接字连接的会话中，此参数将被忽略，并且始终读取为零。

​    在Windows上，值0将将此参数设置为2小时，因为Windows没有提供读取系统默认值的方法。

`tcp_keepalives_interval` (`integer`)

​    指定秒数，在此秒数之后，客户端未确认的TCP keepalive消息应重新传输。 值0使用系统默认值。 仅在支持TCP_KEEPINTVL或等效套接字选项的系统以及Windows上才支持此参数。 在其他系统上，它必须为零。 在通过Unix域套接字连接的会话中，此参数将被忽略，并且始终读取为零。

​    在Windows上，值0将将此参数设置为1秒，因为Windows没有提供读取系统默认值的方法。

`tcp_keepalives_count` (`integer`)

​    指定在服务器与客户端的连接被视为无效之前可以丢失的TCP keepalive数量。 值0使用系统默认值。 仅在支持TCP_KEEPCNT或等效套接字选项的系统上支持此参数。 在其他系统上，它必须为零。 在通过Unix域套接字连接的会话中，此参数将被忽略，并且始终读取为零。

​    Windows不支持此参数，并且必须为零。

##### Security and Authentication

`authentication_timeout` (`integer`)

​    完成客户端身份验证的最长时间，以秒为单位。 如果准客户在这段时间内没有完成身份验证协议，则服务器将关闭连接。 这样可以防止挂起的客户端无限期占用连接。 默认值为一分钟（1m）。 该参数只能在postgresql.conf文件或服务器命令行中设置。

`ssl` (`boolean`)

​    启用SSL连接。 请在使用前阅读第18.9节。 该参数只能在postgresql.conf文件或服务器命令行中设置。 默认为关闭。

`ssl_ca_file` (`string`)

​    指定包含SSL服务器证书颁发机构（CA）的文件的名称。 相对路径是相对于数据目录的。 该参数只能在postgresql.conf文件或服务器命令行中设置。 默认值为空，表示未加载CA文件，并且不执行客户端证书验证
​    在先前的PostgreSQL版本中，此文件的名称硬编码为root.crt。

`ssl_cert_file` (`string`)

​    指定包含SSL服务器证书的文件的名称。 相对路径是相对于数据目录的。 该参数只能在postgresql.conf文件或服务器命令行中设置。 默认值为server.crt。

`ssl_crl_file` (`string`)

​    指定包含SSL服务器证书吊销列表（CRL）的文件的名称。 相对路径是相对于数据目录的。 该参数只能在postgresql.conf文件或服务器命令行中设置。 默认为空，表示未加载任何CRL文件。
​    在先前的PostgreSQL版本中，此文件的名称硬编码为root.crl。

`ssl_key_file` (`string`)

​    指定包含SSL服务器私钥的文件的名称。 相对路径是相对于数据目录的。 该参数只能在postgresql.conf文件或服务器命令行中设置。 默认值为server.key。

`ssl_ciphers` (`string`)

​    指定允许在安全连接上使用的SSL密码套件的列表。有关此设置的语法和支持的值的列表，请参见OpenSSL软件包中的密码手册页。该参数只能在postgresql.conf文件或服务器命令行中设置。默认值为HIGH：MEDIUM：+ 3DES：！aNULL。除非您有特定的安全要求，否则默认值通常是一个合理的选择。
默认值的说明：
高
使用HIGH组密码的密码套件（例如AES，Camellia，3DES）
中
使用MEDIUM组密码的密码套件（例如RC4，SEED）

3DES
HIGH的OpenSSL默认顺序是有问题的，因为它比AES128高3DES。这是错误的，因为3DES提供的安全性低于AES128，并且速度也慢得多。 + 3DES在所有其他高和中密码之后对其重新排序。
！aNULL
禁用不进行身份验证的匿名密码套件。这样的密码套件容易受到中间人攻击，因此不应使用。
可用的密码套件详细信息将在OpenSSL版本中有所不同。使用命令openssl ciphers -v'HIGH：MEDIUM：+ 3DES：！aNULL'查看当前安装的OpenSSL版本的实际详细信息。请注意，此列表在运行时根据服务器密钥类型进行过滤。

`ssl_prefer_server_ciphers` (`boolean`)

​    指定是否使用服务器的SSL密码首选项而不是客户端的SSL密码首选项。 该参数只能在postgresql.conf文件或服务器命令行中设置。 默认值为true。
​    较早的PostgreSQL版本没有此设置，并且始终使用客户端的首选项。 此设置主要是为了与这些版本向后兼容。 通常，使用服务器的首选项会更好，因为更可能是正确配置了服务器。

`ssl_ecdh_curve` (`string`)

​    指定在ECDH密钥交换中使用的曲线的名称。 所有连接的客户端都需要支持它。 它不必与服务器的“椭圆曲线”键使用的曲线相同。 该参数只能在postgresql.conf文件或服务器命令行中设置。 默认值为prime256v1。
最常见曲线的OpenSSL名称是：prime256v1（NIST P-256），secp384r1（NIST P-384），secp521r1（NIST P-521）。 可用曲线的完整列表可以使用命令openssl ecparam -list_curves显示。 但是，并非所有这些功能都可以在TLS中使用。

`password_encryption` (`enum`)

​    在CREATE ROLE或ALTER ROLE中指定了密码后，此参数确定用于加密密码的算法。 默认值为md5，它将密码存储为MD5哈希（也接受on，作为md5的别名）。 将此参数设置为scram-sha-256将使用SCRAM-SHA-256加密密码。
​    请注意，较旧的客户端可能缺乏对SCRAM身份验证机制的支持，因此不适用于使用SCRAM-SHA-256加密的密码。 有关更多详细信息，请参见第20.3.2节。

`ssl_dh_params_file` (`string`)

​    指定包含用于Diffie-Hellman参数的文件的名称，这些参数用于所谓的短暂DH系列SSL密码。 默认值为空，在这种情况下，将使用已编译的默认DH参数。 如果攻击者设法破解众所周知的内置DH参数，则使用自定义DH参数可以减少暴露。     您可以使用命令openssl dhparam -out dhparams.pem 2048创建自己的DH参数文件。该参数只能在postgresql.conf文件或服务器命令行中设置。

`krb_server_keyfile` (`string`)

​    设置Kerberos服务器密钥文件的位置。 有关详细信息，请参见第20.3.3节。 该参数只能在postgresql.conf文件或服务器命令行中设置。

`krb_caseins_users` (`boolean`)

​    设置是否应不区分大小写地对待GSSAPI用户名。 默认为关闭（区分大小写）。 该参数只能在postgresql.conf文件或服务器命令行中设置。

`db_user_namespace` (`boolean`)

​    此参数启用每个数据库的用户名。默认情况下它是关闭的。该参数只能在postgresql.conf文件或服务器命令行中设置。
如果启用，则应将用户创建为username @ dbname。当连接的客户端传递用户名时，@和数据库名将附加到用户名后，服务器将查找该特定于数据库的用户名。请注意，在SQL环境中使用包含@的名称创建用户时，需要用引号引起来。
启用此参数后，您仍然可以创建普通的全局用户。在客户端中指定用户名时，只需添加@，例如jone@。在服务器查找用户名之前，@将被删除。
​    db_user_namespace导致客户端和服务器的用户名表示形式不同。身份验证检查始终使用服务器的用户名进行，因此必须为服务器的用户名（而不是客户端的用户名）配置身份验证方法。因为md5在客户端和服务器上都使用用户名作为盐，所以md5不能与db_user_namespace一起使用。

在找到完整的解决方案之前，此功能仅用作临时措施。 届时，该选项将被删除。

#### Resource Consumption

##### Memory

`shared_buffers` (`integer`)

​    设置数据库服务器用于共享内存缓冲区的内存量。默认值通常为128兆字节（128MB），但是如果您的内核设置不支持该默认值，则该值可能会更少（由initdb确定）。此设置必须至少为128 KB。 （BLCKSZ的非默认值会更改最小值。）但是，为了获得良好的性能，通常需要使用高于该最小值的设置。该参数只能在服务器启动时设置。

​    如果您有一个具有1GB或更大RAM的专用数据库服务器，则shared_buffers的合理起始值是系统内存的25％。在某些工作负载中，更大的shared_buffers设置是有效的，但是由于PostgreSQL也依赖于操作系统缓存，因此分配shared_buffers的RAM的40％以上不太可能比较小的RAM更好。较大的shared_buffers设置通常需要相应增加max_wal_size，以便在更长的时间内分散写入大量新数据或更改数据的过程。

​    在具有少于1GB RAM的系统上，较小百分比的RAM是合适的，以便为操作系统留出足够的空间。

`huge_pages` (`enum`)

​    启用/禁用大内存页的使用。 有效值为try（默认值），on和off。
​    目前，只有Linux才支持此功能。 尝试设置时，该设置在其他系统上将被忽略。使用大页面可导致页面表更小，并减少用于内存管理的CPU时间，从而提高性能。 有关更多详细信息，请参见第18.4.5节。
​    尝试设置huge_pages时，服务器将尝试使用大页面，但是如果失败，则退回到使用常规分配。 启用后，无法使用大页面将阻止服务器启动。 如果关闭，将不会使用大页面。

`temp_buffers` (`integer`)

​    设置每个数据库会话使用的最大临时缓冲区数。 这些是会话本地缓冲区，仅用于访问临时表。 默认值为八兆字节（8MB）。 可以在单个会话中更改设置，但只能在会话中首次使用临时表之前进行更改； 随后尝试更改该值将对该会话无效。

​    会话将根据需要分配临时缓冲区，直到temp_buffers给定的限制。 在实际上不需要许多临时缓冲区的会话中设置大值的代价只是temp_buffers中每个增量的缓冲区描述符，或大约64个字节。 但是，如果实际上使用了缓冲区，则会为此消耗额外的8192字节（或者通常是BLCKSZ字节）。

`max_prepared_transactions` (`integer`)

​    设置可以同时处于“准备”状态的最大事务数（请参阅PREPARE TRANSACTION）。将此参数设置为零（这是默认值）将禁用准备事务功能。该参数只能在服务器启动时设置。

​    如果您不打算使用准备好的交易，则应将此参数设置为零，以防止意外创建准备好的交易。如果您使用准备好的事务，则可能希望max_prepared_transactions至少与max_connections一样大，以便每个会话都可以有一个准备好的事务挂起。

​    运行备用服务器时，必须将此参数设置为与主服务器上相同或更高的值。否则，备用服务器将不允许查询。即使您的应用程序未明确发出PREPARE TRANSACTION，当更新事务涉及多个Coordinator和Datanode时，Coordinator仍会生成此命令。对于数据节点，应将此值指定为与max_connections相同的值。

`work_mem` (`integer`)

​    指定内部排序操作和哈希表在写入临时磁盘文件之前要使用的内存量。 该值默认为四个兆字节（4MB）。 请注意，对于复杂的查询，可能会并行运行多个排序或哈希操作。 在开始将数据写入临时文件之前，每个操作将被允许使用此值指定的内存量。 另外，几个正在运行的会话可能会同时进行此类操作。 因此，使用的总内存可能是work_mem的许多倍； 选择值时必须牢记这一事实。 排序操作用于ORDER BY，DISTINCT和合并联接。 哈希表用于IN子查询的哈希联接，基于哈希的聚合和基于哈希的处理。

`maintenance_work_mem` (`integer`)

​    指定维护操作（例如VACUUM，CREATE INDEX和ALTER TABLE ADD FOREIGN KEY）使用的最大内存量。 默认为64兆字节（64MB）。 由于一次数据库会话一次只能执行这些操作中的一个，并且安装中通常不会同时运行多个操作，因此将这个值设置为明显大于work_mem是安全的。 较大的设置可能会提高清理和还原数据库转储的性能。
​    请注意，在运行autovacuum时，最多可以分配autovacuum_max_workers乘以该内存，因此请注意不要将默认值设置得太高。 通过单独设置autovacuum_work_mem对此进行控制可能很有用。