18.1. 设置参数

18.1.1. 参数名和值

所有参数名都是大小写不敏感的。每个参数都可以接受四种类型之一: 布尔、整数、浮点数、字符串。布尔值可以是(都是大小写无关) on, off, true, false, yes, no, 1, 0 或这些东西的任意清晰无歧义的前缀。

一些设置指定内存或时间值,其隐含的单位可能是: kB(千字节)、块(通常是8KB)、毫秒、秒、分钟等等。 隐含单位可以通过引用pg_settings.unit获取。为了避免混淆, 可以在指定数值的同时指定单位。可用内存单位:kB(千字节), MB(兆字节), GB(吉字节); 可用时间单位:ms(毫秒), s(秒), min(分钟), h(小时), d(天)。 内存单位中的"千"等于1024, 而不是1000。

作为字符串参数的同样方式指定"枚举"类型参数,但被限制在值的有限集合中。 可以从pg_settings.enumvals找到允许的值。 枚举参数值是不区分大小写的。

18.1.2. 通过配置文件设置参数

设置这些参数的一个方法是编辑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处理中也被忽略(但已登录)。

18.1.3. 设置参数其他的方法

第二种设置这些配置参数的方法是把它们作为命令行参数传递给postgres,比如:

postgres -c log_connections=yes -c log_destination='syslog'

命令行选项覆盖postgresql.conf中的矛盾设置。请注意, 这意味着你不能通过编辑postgresql.conf在运行时改变其数值,因此, 虽然命令行方法很方便,但会付出灵活性的代价。

有时候,给某一个特定会话一个命令行参数也是很有用的。 可以在客户端使用环境变量PGOPTIONS 来实现这个目的:

env PGOPTIONS='-c geqo=off' psql

(可以用于任何基于libpq的客户端应用, 不光是psql): 请注意,这个变量对那些需要在服务器启动后固定的选项或者 必须在postgresql.conf里声明的选项是无效的。

并且,我们可以给一个用户或者一个数据库赋予一套选项设置。 在一个会话开始的时候,装载所涉及到的用户和数据库的缺省设置。 命令ALTER ROLEALTER DATABASE 分别用于配置这些设置。 针对每个数据库的设置将覆盖任何从postgres命令行或者配置文件收到的设置, 然后接着又被针对每个用户的设置覆盖; 最后又会都被针对每个会话的设置覆盖。

一些选项可以在独立的SQL会话中修改,方法是使用SET命令,比如:

SET ENABLE_SEQSCAN TO OFF;

如果允许用SET设置,这种针对每个数据库的设置将覆盖任何来自其它方面的设置。 有些参数不能通过SET改变:比如,如果这些选项不重启动PostgreSQL就无法合理控制其行为。 同样,有些参数只能由超级用户通过SETALTER修改,而普通用户不能修改。

18.1.4. 检查参数设置

SHOW命令检查所有参数的当前值。

我们也可以用虚表pg_settings 来显示和更新当前会话的运行时参数。当它们改变时,参见Section 47.66获取详细信息,以及不同变量类型的描述。 pg_settings等效于SHOWSET,但是用起来更方便,因为它可以和其它表连接起来使用, 或者用任意用户需要的选择条件来查询。 它还包含了来自SHOW的每个参数的更多详细信息。

18.1.5. 配置文件包含

除了参数设置外,postgresql.conf文件还包含include指令, 它声明了另外一个文件的读取和处理,正如在这一点上插入到配置文件。 这个特性允许配置文件被分成物理上独立部分。 Include指令看起来像:

include 'filename'

如果文件名不是绝对路径,那么它被看成包含引用配置文件目录的相对路径。 可以进行嵌套。

此外,还有一个include_if_exists指令,它的作用和 include指令是相同的,除了被引用的文件不存在或无法读取时的行为。 规则的include会认为这是一个错误条件,但include_if_exists 只是记录一条消息,并继续处理引用的配置文件。

postgresql.conf文件也包含include_dir指令,声明了配置文件的 整个目录,它的类似用法:

 include_dir 'directory'

非绝对路径遵循和单个文件包括指令相同的规则, 它们是相对于包含引用的配置文件目录。在该目录中,唯一一个非目录的文件, 其名以后缀.conf的将被包括在内。 文件名以.字符开头的被排除在外, 为防止出错,它们都隐藏在一些平台上。在include目录中的多个文件 按照文件名的顺序进行处理。 文件名按照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

这样的安排使每个配置文件的变化具有唯一名称。 当一些服务器的配置都存储在一个地方的时候,这可以帮助消除歧义。比如版本 控制存储(版本控制下存储数据库配置文件是另一种很好的做法)。