有很多配置参数可以影响数据库系统的行为。本章的第一节中我们将描述一下如何与配置参数交互。 后续的小节将详细地讨论每一个参数。
所有参数名都是大小写不敏感的。每个参数都可以接受五种类型之一的值: 布尔、字符串、整数、 浮点数或枚举。该类型决定了设置该参数的语法:
设置这些参数最基本的方法是编辑postgresql.conf文件, 它通常被保存在数据目录中(当数据库集簇目录被初始化时,一个默认的拷贝将会被安装在那里)。一个该文件的例子看起来是:
# This is a comment
log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
每一行指定一个参数。名称和值之间的等号是可选的。空白是无意义的(除了在一个引号引用的参数值内)并且空行被忽略。井号(#)指示该行的剩余部分是一个注释。非简单标识符或者数字的参数值必须用单引号包围。要在参数值里嵌入单引号, 要么写两个单引号(首选)或者在引号前放反斜线。
以这种方式设定的参数为集簇提供了默认值。除非这些设置被覆盖,活动会话看到的就是这些设置。 下面的小节描述了管理员或用户覆盖这些默认值的方法。
主服务器进程每次收到SIGHUP信号(最简单的方法是从命令行运行pg_ctl reload
或调用 SQL 函数pg_reload_conf()
来发送这个信号)后都会重新读取这个配置 文件。主服务器进程还会把这个信号传播给所有正在运行的服务器进程,这样现有的会话也能采用新 值(要等待它们完成当前正在执行的客户端命令之后才会发生)。另外,你可以直接向一个单一服务 器进程发送该信号。有些参数只能在服务器启动时设置,在配置文件中对这些条目的修改将被忽略, 直到下次服务器重启。配置文件中的非法参数设置也会在SIGHUP处理过程中被 忽略(但是会记录日志)。
除postgresql.conf
之外,PostgreSQL 数据目录还包含一个文件 postgresql.auto.conf
,它具有和postgresql.conf
相同的格式但是不应该被手工编辑。这个 文件保存了通过ALTER SYSTEM命令提供的设置。每当postgresql.conf
被读 取时这个文件会被自动读取,并且它的设置会以同样的方式生效。 postgresql.auto.conf
中的设置会覆盖postgresql.conf
中的设置。
系统视图pg_file_settings 可以有助于对配置文件中的更改进行提前测试,或者在SIGHUP信号没有达到预期效果时用来诊断问题。
PostgreSQL提供了三个SQL命令来建立配置默认值。 已经提到过的ALTER SYSTEM命令提供了一种改变全局默认值的从SQL可 访问的方法;它在功效上等效于编辑postgresql.conf
。此外,还有两个命令 可以针对每个数据库或者每个角色设置默认值:
一旦一个客户端连接到数据库,PostgreSQL会提供两个额外的SQL命令( 以及等效的函数)用以影响会话本地的配置设置:
current_setting(setting_name text)
。set_config(setting_name, new_value, is_local)
。
此外,系统视图pg_settings可以被用来查看和改变 会话本地的值:SET configuration_parameter TO DEFAULT;
等效于:
UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';
除了在数据库或者角色层面上设置全局默认值或者进行覆盖,你还可以通过 shell 工具把设置传递给PostgreSQL。服务器和libpq 客户端库都能通过 shell 接受参数值。
在服务器启动期间,可以通过-c命令行参数把参数设置传递给 postgres命令。例如:
postgres -c log_connections=yes -c log_destination='syslog'
这种方式提供的设置会覆盖通过postgresql.conf或者 ALTER SYSTEM提供的设置,因此除了重启服务器之外无法从全局上改变它们。
env PGOPTIONS="-c geqo=off -c statement_timeout=5min" psql
通过 shell 或者其他方式,其他客户端和库可能提供它们自己的机制,以便允许用户在不直接 使用SQL命令的前提下修改会话设置。
PostgreSQL提供了一些特性用于把复杂的 postgresql.conf文件分解成子文件。在管理多个具有相关但不完全相同 配置的服务器时,这些特性特别有用。
除了单个参数设置,postgresql.conf文件可以包含包括指令,它指定要读入和处理的另一个文件,就好像该文件被插入到配置文件的这个点。这个特性允许一个配置文件被划分成物理上独立的部分。包括指令看起来像:include 'filename'
如果文件名不是一个绝对路径,它将作为包含引用配置文件的目录的相对位置。包括可以被嵌套。
也有一个include_if_exists指令,它的作用和include指令一样,不过当被引用的文件不存在或者无法被读取时其行为不同。一个通常的include将认为这是一个错误情况,而include_if_exists
仅仅记录一个消息并且继续处理引用配置文件。
postgresql.conf文件也可以包含include_dir指令,它指定要被包含的配置文件的一整个目录。它的用法类似:include_dir 'directory'
非绝对目录名被当做包含引用配置文件的目录的相对路径。在该指定目录中,只有以后缀名.conf结尾的非目录文件才会被包括。以. 字符开头的文件名也会被忽略,因为在某些平台上它们是隐藏文件。一个包括目录中的多个文件 被以文件名顺序处理(根据 C 区域规则排序,即数字在字母之前并且大写字母在小写字母 之前)。
包括文件或目录可以被用来在逻辑上分隔数据库配置的各个部分,而不是用一个很大的postgresql.conf
文件。考虑一个有两台数据库服务器的公司,每一个都有不同的内存量。很可能配置的元素都会被共享,例如用于日志的参数。但是两者关于内存的参数将会不同。并且还可能会有服务器相关的自定义。一种管理这类情况的方法是将你的站点的自定义配置修改分成三个文件。你可以把下面的内容加入到你的postgresql.conf
文件末尾来包括它们:
include 'shared.conf'
include 'memory.conf'
include 'server.conf'
所有的系统将会有相同的shared.conf。每个有特定内存量的服务器可以共享相同的memory.conf。你可能对所有 8GB 内存的服务器有一个,而对那些 16GB 内存的服务器有另一个。并且最后server.conf可以装有真正服务器相关的配置信息。
另一中可能性是创建一个配置文件目录并把这个信息放到其中的文件里。例如,一个conf.d目录可以在postgresql.conf的末尾被引用:
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
这种形式的安排为每个配置文件变体给定了一个唯一的名称。当多个服务器把它们的配置全部存储在一个位置(例如在一个版本控制仓库中)时,这可以帮助消除歧义(在版本控制下存储数据库配置文件是另一个值得考虑的好方法)。