所有参数名都是大小写不敏感的。每个参数都可以接受五种类型之一的值： 布尔、字符串、整数、 浮点数或枚举。该类型决定了设置该参数的语法：
布尔:
值可以被写成
on,
off,
true,
false,
yes,
no,
1,
0
（都是大小写不敏感的）或者这些值的任何无歧义前缀。
字符串: 通常值被包括在单引号内，值内部的任何单引号都需要被双写。不过，如果值是一个简单数字或者 标识符，引号通常可以被省略。 (与 SQL 关键字匹配的值需要在某些上下文中引用。)
数字（整数和浮点）:
数字参数可以规定为惯用的整数和浮点格式；如果参数为整数类型，则小数值四舍五入到最接近的整数。
证书参数还接受十六进制输入(以0x开头)和十进制输入(以0开头)，但是这些格式不能有小数。
不能使用千位分隔符。引号是不是必需的，除了十六进制输入。
带单位的数字:
一些数字参数具有隐含单位，因为它们描述内存或时间量。单位可能是字节、千字节、块（通常是 8KB）、 毫秒、秒或分钟。这些设置之一的一个未修饰的数字值将使用该设置的默认单位，默认单位可以通
过引用pg_settings.unit来找到。为了方便，也可以
显式地指定一个不同的单位，例如时间值可以是'120 ms'，并且它们将被转换到参数的实际单位。要使用这个特性，注意值必须被写成一个字符
串（带有引号）。单位名称是大小写敏感的，并且在数字值和单位之间可以有空白。
可用的内存单位是B（字节）、kB（千字节）、MB（兆字节）和GB（吉字节）。内存单位的乘数是 1024 而不是 1000。
可用的时间单位是
us (微秒),
ms (毫秒),
s（秒）、min（分钟）、
h（小时）和d（天）。
如果一个单位指定了小数值，如果有下一个较小的单元，它将四舍五入为下一个较小单位的倍数。
例如，30.1 GB将被转换为30822 MB而不是32319628902 B。
如果参数为整数类型，则在进行任何单位转换之后，最后四舍五入到整数。
枚举:
枚举类型的参数以与字符串参数相同的方式指定，但被限制到一组有限的值。 这样一个参数可用的值可以在pg_settings.enumvals
中找到。枚举参数值是大小写无关的。
设置这些参数最基本的方法是编辑lightdb.conf文件， 它通常被保存在数据目录中（当数据库实例目录被初始化时，一个默认的拷贝将会被安装在那里）。一个该文件的例子看起来是：
# This is a comment log_connections = yes log_destination = 'syslog' search_path = '"$user", public' shared_buffers = 128MB
每一行指定一个参数。名称和值之间的等号是可选的。空白是无意义的（除了在一个引号引用的参数值内）并且空行被忽略。井号（#）指示该行的剩余部分是一个注释。非简单标识符或者数字的参数值必须用单引号包围。要在参数值里嵌入单引号， 要么写两个单引号（首选）或者在引号前放反斜线。
如果文件包含相同参数的多个条目，则忽略除最后一个之外的所有条目。
以这种方式设定的参数为实例提供了默认值。除非这些设置被覆盖，活动会话看到的就是这些设置。 下面的小节描述了管理员或用户覆盖这些默认值的方法。
主服务器进程每次收到SIGHUP信号（最简单的方法是从命令行运行lt_ctl reload或调用 SQL 函数pg_reload_conf()来发送这个信号）后都会重新读取这个配置
文件。主服务器进程还会把这个信号传播给所有正在运行的服务器进程，这样现有的会话也能采用新
值（要等待它们完成当前正在执行的客户端命令之后才会发生）。另外，你可以直接向一个单一服务
器进程发送该信号。有些参数只能在服务器启动时设置，在配置文件中对这些条目的修改将被忽略，
直到下次服务器重启。配置文件中的非法参数设置也会在SIGHUP处理过程中被
忽略（但是会记录日志）。
除lightdb.conf之外，LightDB
数据目录还包含一个文件lightdb.auto.conf，
它具有和lightdb.conf相同的格式但是原自动编辑，而不是手工编辑。
这个文件保存了通过ALTER SYSTEM命令提供的设置。
每当lightdb.conf被读取时这个文件会被自动读取，并且它的设置会以同样的方式生效。
lightdb.auto.conf中的设置会覆盖lightdb.conf中的设置。
外部工具也可以修改 lightdb.auto.conf.
不建议在服务器运行时执行此操作，因为并发的 ALTER SYSTEM 可能会覆盖这些更改。
这些工具可能只是简单地在末尾附加新的设置，或者它们可能删除重复的设置和/或注释(就像 ALTER SYSTEM )。
系统视图pg_file_settings
可以有助于对配置文件中的更改进行提前测试，或者在SIGHUP
信号没有达到预期效果时用来诊断问题。
LightDB提供了三个SQL命令来建立配置默认值。
已经提到过的ALTER SYSTEM命令提供了一种改变全局默认值的从SQL可
访问的方法；它在功效上等效于编辑lightdb.conf。此外，还有两个命令
可以针对每个数据库或者每个角色设置默认值：
ALTER DATABASE命令允许针对一个数据库覆盖其全局设置。
ALTER ROLE命令允许用用户指定的值来覆盖全局设置和数据库设置。
只有当开始一个新的数据库会话时，用ALTER DATABASE和
ALTER ROLE设置的值才会被应用。它们会覆盖从配置文件或服务器命令行
获得的值，并且作为该会话后续的默认值。注意某些设置在服务器启动后不能被更改，并且因此
不能被这些命令（或者下文列举的命令）设置。
以上3种修改参数的方式，都会在日志文件（位于$LTDATA/log中）中详细记录参数的修改情况：包
括参数修改前的值，参数修改后的值，以及修改参数的时间、客户端程序名、修改参数的用户、修
改参数使用的具体SQL语句。同时当执行ALTER DATABASE、ALTER DATABASE或ALTER ROLE
时还会在客户端程序中提示参数修改前和修改后的值。
一旦一个客户端连接到数据库，LightDB会提供两个额外的SQL命令（ 以及等效的函数）用以影响会话本地的配置设置：
SHOW命令允许察看任何参数的当前值。对应的SQL函数是
current_setting(setting_name text) (参见 Section 10.27.1)。
SET命令允许修改对于一个会话可以本地设置的参数的当前值，它对其他会话没有影响。
对应的SQL函数是 set_config(setting_name, new_value, is_local) (参见 Section 10.27.1)。
此外，系统视图pg_settings可以被用来查看和改变
会话本地的值：
查询这个视图与使用SHOW ALL相似，但是可以提供更多细节。它也更加灵活，
因为可以为它指定过滤条件或者把它与其他关系进行连接。
在这个视图上使用UPDATE并且指定更新setting
列，其效果等同于发出SET命令。例如，下面的命令
SET configuration_parameter TO DEFAULT;
等效于：
UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';
除了在数据库或者角色层面上设置全局默认值或者进行覆盖，你还可以通过 shell 工具把设置 传递给LightDB。服务器和libpq 客户端库都能通过 shell 接受参数值。
在服务器启动期间，可以通过-c命令行参数把参数设置传递给
lightdb命令。例如：
lightdb -c log_connections=yes -c log_destination='syslog'
这种方式提供的设置会覆盖通过lightdb.conf或者
ALTER SYSTEM提供的设置，因此除了重启服务器之外无法从全局上改变它们。
当通过libpq启动一个客户端会话时，可以使用PGOPTIONS
环境变量指定参数设置。这种方式建立的设置构成了会话生存期间的默认值，但是不会影响
其他的会话。由于历史原因，LTOPTIONS的格式和启动
lightdb命令时用到的相似，特别是-c标志必须被指定。
例如：
env PGOPTIONS="-c geqo=off -c statement_timeout=5min" ltsql
通过 shell 或者其他方式，其他客户端和库可能提供它们自己的机制，以便允许用户在不直接 使用SQL命令的前提下修改会话设置。
LightDB提供了一些特性用于把复杂的
lightdb.conf文件分解成子文件。在管理多个具有相关但不完全相同
配置的服务器时，这些特性特别有用。
除了单个参数设置，lightdb.conf文件可以包含包括指令，它指定要读入和处理的另一个文件，就好像该文件被插入到配置文件的这个点。这个特性允许一个配置文件被划分成物理上独立的部分。包括指令看起来像：
include 'filename'
如果文件名不是一个绝对路径，它将作为包含引用配置文件的目录的相对位置。包括可以被嵌套。
也有一个include_if_exists指令，它的作用和include指令一样，不过当被引用的文件不存在或者无法被读取时其行为不同。一个通常的include将认为这是一个错误情况，而include_if_exists仅仅记录一个消息并且继续处理引用配置文件。
lightdb.conf文件也可以包含include_dir指令，它指定要被包含的配置文件的一整个目录。它的用法类似：
include_dir 'directory'
非绝对目录名被当做包含引用配置文件的目录的相对路径。在该指定目录中，只有以后缀名
.conf结尾的非目录文件才会被包括。以.
字符开头的文件名也会被忽略，因为在某些平台上它们是隐藏文件。一个包括目录中的多个文件
被以文件名顺序处理（根据 C 区域规则排序，即数字在字母之前并且大写字母在小写字母
之前）。
包括文件或目录可以被用来在逻辑上分隔数据库配置的各个部分，而不是用一个很大的lightdb.conf文件。
考虑一个有两台数据库服务器的公司，每一个都有不同的内存量。
很可能配置的元素都会被共享，例如用于日志的参数。但是两者关于内存的参数将会不同。
并且还可能会有服务器相关的自定义。
一种管理这类情况的方法是将你的站点的自定义配置修改分成三个文件。
你可以把下面的内容加入到你的lightdb.conf文件末尾来包括它们：
include 'shared.conf' include 'memory.conf' include 'server.conf'
所有的系统将会有相同的shared.conf。
每个有特定内存量的服务器可以共享相同的memory.conf。
你可能对所有 8GB 内存的服务器有一个，而对那些 16GB 内存的服务器有另一个。
并且最后server.conf可以装有真正服务器相关的配置信息。
另一中可能性是创建一个配置文件目录并把这个信息放到其中的文件里。
例如，一个conf.d目录可以在lightdb.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
这种形式的安排为每个配置文件变体给定了一个唯一的名称。当多个服务器把它们的配置全部存储在一个位置（例如在一个版本控制仓库中）时，这可以帮助消除歧义（在版本控制下存储数据库配置文件是另一个值得考虑的好方法）。