所有参数名都是大小写不敏感的。每个参数都接受五种类型之一的值：布尔、整数、浮点数、 字符串或枚举。布尔值可以被写成 on、 off、true、 false、yes、 no、1、0 （都是大小写不敏感的）或者这些值的任何无歧义前缀。

有些设置指定内存或时间值。其中每一种都有一个隐含单位，即千字节、块（通常是八千字节）、 毫秒、秒或分钟之一。默认单位可以通过 pg_settings.unit 查到。为方便起见，也可以显式指定一个不同的单位。有效的内存单位有 kB（千字节）、MB （兆字节）和 GB（吉字节）；有效的时间单位有 ms（毫秒）、s （秒）、min（分钟）、h （小时）和 d（天）。注意内存单位的乘数是 1024 而不是 1000。

“枚举”类型参数的指定方式与字符串参数相同，但被限制为一组有限的值。 允许的值可以从 pg_settings.enumvals 查到。枚举参数值是大小写不敏感的。

设置这些参数最基本的方法是编辑文件 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处理过程中被 忽略（但是会记录日志）。

设置这些配置参数的第二种方法是把它们作为 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 ROLE 和 ALTER DATABASE 命令来配置这些设置。每个数据库的设置覆盖从 postgres 命令行或配置文件收到的任何内容， 而后者又被每用户的设置覆盖；两者都会被每会话的设置覆盖。

有些参数可以在各个 SQL 会话中用 SET 命令更改，例如：

SET ENABLE_SEQSCAN TO OFF;

如果允许 SET，它将覆盖该参数所有其他来源的值。有些参数不能通过 SET 更改：例如，控制在不重启整个 PostgreSQL 服务器的情况下无法更改的行为的参数。此外，有些参数需要超级用户权限才能通过 SET 或 ALTER 更改。

SHOW 命令允许查看所有参数的当前值。

虚拟表 pg_settings 也允许显示和更新会话运行时参数；详见 第 47.66 节，其中有对不同变量类型及何时可以更改它们的描述。 pg_settings 等价于 SHOW 和 SET，但用起来可能更方便，因为它可以与其他表连接，或者用任何想要的选择条件来查询。 它还包含比 SHOW 可得的每个参数更多的信息。

除了单个参数设置之外，postgresql.conf 文件还可以包含 include 指令，用来指定另一个要读取和处理的文件，就像把该文件插入到配置文件的这个位置一样。 这一特性允许把一个配置文件拆分成多个物理上独立的部分。include 指令的形式如下：

include 'filename'

如果文件名不是绝对路径，则会被解释为相对于引用它的配置文件所在目录的路径。include 可以嵌套。

还有一个 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
 

这种形式的安排为每个配置文件变体给定了一个唯一的名称。当多个服务器把它们的配置全部存储在一个位置（例如在一个版本控制仓库中）时，这可以帮助消除歧义（在版本控制下存储数据库配置文件是另一个值得考虑的好方法）。