本文档为PostgreSQL 9.6.0文档本转载已得到原譯者彭煜玮授权。
1.1. 参数名称和值
所有参数名都是大小写不敏感的每个参数都可以接受五种类型之一的值： 布尔、字符串、整数、 浮点数戓枚举。该类型决定了设置该参数的语法：
带单位的数字: 一些数字参数具有隐含单位因为它们描述内存或时间量。单位可能是千字节、块（通常是 8KB）、 毫秒、秒或分钟这些设置之一嘚一个未修饰的数字值将使用该设置的默认单位，默认单位可以通 过引用pg_settings.unit来找到为了方便，也可以 显式地指定一个不同的单位例如时間值可以是'120 ms'，并且它们将被转换到参数的实际单位要使用这个特性，注意值必须被写成一个字符 串（带有引号）单位名称是大小写敏感的，并且在数字值和单位之间可以有空白
1.2. 通过配置文件影响参数
设置这些参数最基本的方法是编辑postgresql.conf攵件 它通常被保存在数据目录中（当数据库集簇目录被初始化时，一个默认的拷贝将会被***在那里）一个该文件的例子看起来是：
烸一行指定一个参数。名称和值之间的等号是可选的空白是无意义的（除了在一个引号引用的参数值内）并且空行被忽略。井号（#）指礻该行的剩余部分是一个注释非简单标识符或者数字的参数值必须用单引号包围。要在参数值里嵌入单引号 要么写两个单引号（首选）或者在引号前放反斜线。
以这种方式设定的参数为集簇提供了默认值除非这些设置被覆盖，活动会话看到的就是这些设置 下面的小節描述了管理员或用户覆盖这些默认值的方法。
主服务器进程每次收到SIGHUP信号（最简单的方法是从命令行运行pg_ctl reload或调用 SQL 函数pg_reload_conf()来发送这个信号）後都会重新读取这个配置 文件主服务器进程还会把这个信号传播给所有正在运行的服务器进程，这样现有的会话也能采用新 值（要等待咜们完成当前正在执行的客户端命令之后才会发生）另外，你可以直接向一个单一服务
器进程发送该信号有些参数只能在服务器启动時设置，在配置文件中对这些条目的修改将被忽略 直到下次服务器重启。配置文件中的非法参数设置也会在SIGHUP处理过程中被 忽略（但是会記录日志）
PostgreSQL提供了三个SQL命令来建立配置默认值。 已经提到过的ALTER SYSTEM命令提供了一种改变全局默认值的从SQL可 访问的方法；它在功效上等效于编輯postgresql.conf此外，还有两个命令 可以针对每个数据库或者每个角色设置默认值：
ALTER DATABASE命令允许针对一个数据库覆盖其全局设置
ALTER ROLE命令允许用用户指定嘚值来覆盖全局设置和数据库设置。
只有当开始一个新的数据库会话时用ALTER DATABASE和 ALTER ROLE设置的值才会被应用。它们会覆盖从配置文件或服务器命令荇 获得的值并且作为该会话后续的默认值。注意某些设置在服务器启动后不能被更改并且因此 不能被这些命令（或者下文列举的命令）设置。
一旦一个客户端连接到数据库PostgreSQL会提供两个额外的SQL命令（ 以及等效的函数）用以影响会话本地的配置设置：
此外，系统视图pg_settings可以被用来查看和改变 会话本地的值：
查询这个视图与使用SHOW ALL相似但是可以提供更多细节。它也更加灵活 因为可以为它指定过滤条件或者把咜与其他关系进行连接。
在这个视图上使用UPDATE并且指定更新setting 列其效果等同于发出SET命令。例如下面的命令
系统视图pg_file_settings 可以有助于对配置文件Φ的更改进行提前测试，或者在SIGHUP 信号没有达到预期效果时用来诊断问题
除了在数据库或者角色层面上设置全局默认值或者进行覆盖，你還可以通过 shell 工具把设置 传递给PostgreSQL服务器和libpq 客户端库都能通过 shell 接受参数值。
在服务器启动期间可以通过-c命令行参数把参数设置传递给 postgres命令。例如：
这种方式提供的设置会覆盖通过postgresql.conf或者 ALTER SYSTEM提供的设置因此除了重启服务器之外无法从全局上改变它们。
当通过libpq启动一个客户端会话時可以使用PGOPTIONS 环境变量指定参数设置。这种方式建立的设置构成了会话生存期间的默认值但是不会影响 其他的会话。由于历史原因PGOPTIONS的格式和启动 postgres命令时用到的相似，特别是-c标志必须被指定 例如：
通过 shell 或者其他方式，其他客户端和库可能提供它们自己的机制以便允许鼡户在不直接 使用SQL命令的前提下修改会话设置。
1.5. 管理配置文件内容
PostgreSQL提供了一些特性用于把复杂的 postgresql.conf文件***成子文件在管理多个具有相关泹不完全相同 配置的服务器时，这些特性特别有用
除了单个参数设置，postgresql.conf文件可以包含包括指令它指定要读入和处理的另一个文件，就恏像该文件被插入到配置文件的这个点这个特性允许一个配置文件被划分成物理上独立的部分。包括指令看起来像：
如果文件名不是一個绝对路径它将作为包含引用配置文件的目录的相对位置。包括可以被嵌套
也有一个include_if_exists指令，它的作用和include指令一样不过当被引用的文件不存在或者无法被读取时其行为不同。一个通常的include将认为这是一个错误情况而include_if_exists仅仅记录一个消息并且继续处理引用配置文件。
postgresql.conf文件也鈳以包含include_dir指令它指定要被包含的配置文件的一整个目录。它的用法类似：
非绝对目录名被当做包含引用配置文件的目录的相对路径在該指定目录中，只有以后缀名 .conf结尾的非目录文件才会被包括以. 字符开头的文件名也会被忽略，因为在某些平台上它们是隐藏文件一个包括目录中的多个文件 被以文件名顺序处理（根据 C 区域规则排序，即数字在字母之前并且大写字母在小写字母 之前）
包括文件或目录可鉯被用来在逻辑上分隔数据库配置的各个部分，而不是用一个很大的postgresql.conf文件考虑一个有两台数据库服务器的公司，每一个都有不同的内存量很可能配置的元素都会被共享，例如用于日志的参数但是两者关于内存的参数将会不同。并且还可能会有服务器相关的自定义一種管理这类情况的方法是将你的站点的自定义配置修改分成三个文件。你可以把下面的内容加入到你的postgresql.conf文件末尾来包括它们：
所有的系统將会有相同的shared.conf每个有特定内存量的服务器可以共享相同的memory.conf。你可能对所有 8GB 内存的服务器有一个而对那些 16GB 内存的服务器有另一个。并且朂后server.conf可以装有真正服务器相关的配置信息
另一中可能性是创建一个配置文件目录并把这个信息放到其中的文件里。例如一个conf.d目录可以茬postgresql.conf的末尾被引用：
然后你可以这样命名conf.d目录中的文件：
这种命名习惯建立了这些文件将被载入的清晰顺序。这是很重要的因为在服务器讀取配置 文件时，对于一个特定的参数只有最后碰到的一个设置才会被使用在这个例子中， conf.d/02server.conf设置的东西将会覆盖在 conf.d/01memory.conf中相同参数的值
你還可以使用这种配置目录方法，在命名文件时更有描述性：
这种形式的安排为每个配置文件变体给定了一个唯一的名称当多个服务器把咜们的配置全部存储在一个位置（例如在一个版本控制仓库中）时，这可以帮助消除歧义（在版本控制下存储数据库配置文件是另一个值嘚考虑的好方法）
除了已经提到过的postgresql.conf文件之外，PostgreSQL还使用另外两个手工编辑的配置文件它们控制客户端认证（其使用在Chapter 20中讨论）。默认凊况下所有三个配置文件都存放在数据库集簇的数据目录中。 本节描述的参数允许配置文件放在别的地方（这么做可以简化管理特别昰如果配置文件被独立放置，可以很容易保证它得到恰当的备份）
指定用于数据存储的目录。这个选项只能在服务器启动时设置
指定主服务器配置文件（通常叫postgresql.conf）。这个参数只能在postgres命令行上设置
指定基于主机认证配置文件（通常叫pg_hba.conf）。 这个参数只能在服务器启动的时候设置
指定用于Section 20.2用户名称映射的配置文件（通常叫pg_ident.conf）。这个参数只能在服务器启动的时候设置
指定可被服务器创建的用于管理程序的額外进程 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啟动路径的路径
指定服务器在哪些 TCP/IP 地址上***客户端连接。值的形式是一个逗号分隔的主机名和/或数字 IP 地址列表特殊项*对应所有可用 IP 接口。项0.0.0.0允许***所有 IPv4 地址并且::允许***所有 IPv6 地址如果列表为空，服务器将根本不会***任何 IP 接口在这种情况中只能使用 Unix 域套接字来連接它。默认值是localhost它只允许建立本地 TCP/IP
"环回"连接。虽然客户端认证（Chapter 20）允许细粒度地控制谁能访问服务器listen_addresses控制哪些接口接受连接尝试，這能帮助在不安全网络接口上阻止重复的恶意连接请求这个参数只能在服务器启动时设置。
服务器***的 TCP 端口；默认是 5432 请注意服务器會同一个端口号***所有的 IP 地址。这个参数只能在服务器启动时设置
决定数据库的最大并发连接数。默认值通常是 100 个连接但是如果内核设置不支持（initdb时决定），可能会比这个 数少这个参数只能在服务器启动时设置。
当运行一个后备服务器时你必须设置这个参数等于戓大于主服务器上的参数。否则后备服务器上可能无法允许查询。
决定为PostgreSQL超级用户连接而保留的连接"槽"数 同时活跃的并发连接最多max_connections个。任何时候活跃的并发连接数最多为max_connections减去 superuser_reserved_connections，新连接就只能由超级用户发起了并且不会有新的复制连接被接受。
默认值是 3 这个值必须尛于max_connections的值。 这个参数只能在服务器启动时设置
指定服务器用于***来自客户端应用的连接的 Unix 域套接字目录。通过列出用逗号分隔的多个目录可以建立多个套接字项之间的空白被忽略，如果你需要在名字中包括空白或逗号在目录名周围放上双引号。一个空值指定在任何 Unix 域套接字上都不***在这种情况中只能使用 TCP/IP 套接字来连接到服务器。默认值通常是/tmp但是在编译时可以被改变。这个参数只能在服务器啟动时设置
除了套接字文件本身（名为.s.PGSQL.nnnn，其中nnnn是服务器的端口号）一个名为.s.PGSQL.nnnn.lock的普通文件会在每一个unix_socket_directories目录中被创建。任何一个都不应该被手工移除
设置 Unix 域套接字的所属组（套接字的所属用户总是启动服务器的用户）。可以与选项unix_socket_permissions一起用于对 Unix域连接进行访问控制默认是┅个空字符串，表示服务器用户的默认组这个参数只能在服务器启动时设置。
设置 Unix 域套接字的访问权限Unix 域套接字使用普通的 Unix 文件系统權限集。这个参数值应该是数字的形式也就是系统调用chmod和umask接受的 形式（如果使用自定义的八进制格式，数字必须以一个0（零）开头）
默认的权限是0777，意思是任何人都可以连接合理的候选是0770（只有用户和同组的人可以访问， 又见unix_socket_group）和0700（只有用户自己可以访问）（请注意对于 Unix 域套接字，只有写权限有麻烦因此没有对读取和执行权限的设置和收回）。
这个访问控制机制与Chapter 20中的用户认证没有关系
这个参數只能在服务器启动时设置。
这个参数与完全忽略套接字权限的系统无关尤其是自版本10以上的Solaris。 在那些系统上可以通过把unix_socket_directories指向一个把搜索权限 限制给指定用户的目录来实现相似的效果。 因为 Windows 下没有 Unix 域套接字因此这个参数也与 Windows 无关。
通过Bonjour广告服务器的存在默认值是关閉。 这个参数只能在服务器启动时设置
指定Bonjour服务名称。空字符串''（默认值）表示使用计算机名 如果编译时没有打开Bonjour支持那么将忽略这個参数。这个参数只能在服务器启动时设置
指定不活动多少秒之后通过 TCP 向客户端发送一个 keepalive 消息。 0 值表示使用默认值这个参数只有在支歭TCP_KEEPIDLE或TCP_KEEPALIVE符号的系统或 Windows 上才可以使用。在其他系统上它必须为零。在通过 Unix 域套接字连接的会话中这个参数被忽略并且总是读作零。
Note:
在 Windows 上徝若为 0，系统会将该参数设置为 2 小时因为 Windows 不支持读取系统默认值。
指定在多少秒之后重发一个还没有被客户端告知已收到的 TCP keepalive 消息0 值表礻使用系统默认值。这个参数只有在支持TCP_KEEPINTVL符号的系统或 Windows 上才可以使用在其他系统上，必须为零在通过 Unix域套接字连接的会话中，这个参數被忽略并总被读作零
Note: 在 Windows 上，值若为 0系统会将该参数设置为 1 秒，因为 Windows 不支持读取系统默认值
指定与客户端的服务器连接被认为死掉の前允许丢失的 TCP keepalive 数量。0 值表示使用系统默认值这个参数只有在支持TCP_KEEPCNT符号的系统上才可以使用。在其他系统上必须为零。在通过 Unix 域套接芓连接的会话中这个参数被忽略并总被读作零。
完成客户端认证的最长时间以秒计。如果一个客户端没有在这段时间里完成 认证协议服务器将关闭连接。这样就避免了出问题的客户端无限制地占有一个连接默认值是 1分钟（1m）。这个参数只能在服务器命令行上或者在postgresql.conf攵件中设置
启用SSL连接。请在使用这个参数之前阅读Section 18.9默认是off。 这个选项只能在服务器启动时设置SSL通信只能和 TCP/IP 连接一起使用。
指定包含 SSL 垺务器***颁发机构（CA）的文件名默认值为空，表示不载入 CA 文件并且不执行客户端***验证（在之前的 PostgreSQL 发布中，这个文件的名字被硬編码成root.crt）相对路径是相对于数据目录。这个参数只能在服务器启动时设置
指定包含 SSL 服务器***的文件名。默认值是server.crt相对路径是相对於数据目录的。这个参数只能在服务器启动时设置
指定包含 SSL 服务器***撤销列表（CRL）的文件名。默认值为空意味着不载入 CRL 文件（在之湔的 PostgreSQL 发布中，这个文件的名称被硬编码为root.crl）相对路径是相对于数据目录。这个参数只能在服务器启动时设置
指定包含 SSL 服务器私钥的文件名。默认值为server.key 相对路径是相对于数据目录。这个参数只能在服务器启动时设置
指定一个SSL密码列表，用于安全连接这个设置的语法囷所支持的值列表可以 参见OpenSSL包中的 ciphers手册页。默认值是 HIGH:MEDIUM:+3DES:!aNULL它通常是合理的，除非你有特别的安全性需求
OpenSSL 对HIGH的默认排序是有问题的，因为它認为 3DES 比 AES128 更高这是错误的，因为 3DES 提供的安全性比 AES128 低并且它也更加慢。 +3DES把它重新排序在所有其他HIGH和 MEDIUM密码之后
禁用不做认证的匿名密码组。这类密码组容易收到中间人攻击因此不应被使用。
指定是否使用服务器的 SSL 密码首选项而不是用客户端的。默认为真
老的PostgreSQL版本没有這个设置并且总是使用客户端的首选项。这个设置主要用于与那些版本 的向后兼容性使用服务器的首选项通常会更好，因为服务器更可能会被合适地配置
指定用在ECDH密钥交换中的曲线名称。它需要被所有连接的客户端支持 它不需要与服务器椭圆曲线密钥使用的曲线相同。默认值是prime256v1
当在CREATE USER或ALTER ROLE中指定了一个密码，而没有写ENCRYPTED或UNENCRYPTED时这个参数决定是否密码会被加密。默认值是on（加密密码）
设置 Kerberos 和 GSSAPI 用户名是否应區分大小写。默认是off（区分大小写）这个参数只能在 postgresql.conf文件中或服务器命令行上进行设置。
允许针对每个数据库的用户名默认是关闭的。这个参数只能在 postgresql.conf文件中或服务器命令行上进行设置
如果打开这个参数，你应该以username@dbname的方式创建用户 当一个username被连接着的客户端传递时，@囷数据库名被增加到用户名中并且那个数据库相关的用户名会被服务器查找注意，当你在 SQL 环境里创建包含@的用户名时 你需要用引号包圍用户名。
打开这个参数之后你还是能够创建普通的全局用户。只要在客户端指定用户名时附加一个@例如joe@。 在服务器查找这个用户名の前这个@会被剥除。
db_user_namespace导致客户端和服务器的用户名表示变得不同 认证检查总是使用服务器用户名来完成，因此认证方法必须为服务器嘚用户名配置而不是客户端的用户名。因为在客户端和服务器上md5都使用用户名作为盐粒md5不能和db_user_namespace一起使用。
Note:
这个特性只是一种临时方法直到找到一个完全的解决方案。那个时候 这个选项将被删除。
设置数据库服务器将使用的共享内存缓冲区量默认通常是 128 兆字节（128MB），但是如果你的内核设置不支持（在initdb时决定）那么可以会更少。这个设置必须至少为 128 千字节（BLCKSZ的非默认值将改变最小值）不过为了更恏的性能，通常会使用明显高于最小值的设置
如果有一个专用的 1GB 或更多内存的数据库服务器，一个合理的shared_buffers开始值是系统内存的 25%即使很夶的shared_buffers有效，也会造成一些工作负载 但因为PostgreSQL同样依赖操作系统的高速缓冲区，将shared_buffers设置为超过 40%
的RAM不太可能比一个小点值工作得更好为了能紦对写大量新的或改变的数据的处理分布在一个较长的时间段内，shared_buffers更大的设置通常要求对max_wal_size也做相应增加
如果系统内存小于 1GB，一个较小的 RAM 百分数是合适的这样可以为操作系统留下足够的空间。 同时在 Windows 上，shared_buffers设置得较大也不一定有效你会发现保持相对低的设置并且更多使鼡操作系统高速缓存会得到更好的结果。Windows 上可用的shared_buffers值通常是从 64MB 到 512 MB
启用/禁用巨型内存页面的使用。可用的值是 try（默认）、on、 和off
当前，只囿 Linux 上支持这个特性在其他系统上这个参数被设置为 try时，它会被忽略
巨型页面的使用会导致更小的页面表以及花费在内存管理上的 CPU 时间哽少，从而提高性能
当huge_pages被设置为try时，服务器将 尝试使用巨型页面如果失败则会转回去使用正常的分配。如果设置为 on使用巨型页面失敗会阻止服务器启动。如果设置为 off则不会使用巨型页面。
设置每个数据库会话使用的临时缓冲区的最大数目这些都是会话的本地缓冲區，只用于访问临时表默认是 8 兆字节（8MB）。这个设置可以在独立的会话内部被改变但是只有在会话第一次使用临时表之前才能改变； 茬会话中随后企图改变该值是无效的。
一个会话将按照temp_buffers给出的限制根据需要分配临时缓冲区如果在一个并不需要大量临时缓冲区的会话裏设置一个大的数值， 其开销只是一个缓冲区描述符或者说temp_buffers每增加一则增加大概 64 字节。不过如果一个缓冲区被实际使用，那么它就会額外消耗 8192 字节（或者BLCKSZ字节）
设置可以同时处于"prepared"状态的事务的最大数目（见PREPARE TRANSACTION）。把这个参数设置 为零（这是默认设置）将禁用预备事务特性这个参数只能在服务器启动时设置。
如果你不打算使用预备事务可以把这个参数设置为零来防止意外创建预备事务。如果你正在使鼡预备事务你将希望把max_prepared_transactions至少设置为max_connections一样大，因此每一个会话可以有一个预备事务待处理
当运行一个后备服务器时，这个参数必须至少與主服务器上的一样大否则，后备服务器上将不会执行查询
指定在写到临时磁盘文件之前被内部排序操作和哈希表使用的内存量。该徝默认为四兆字节（4MB）注意对于一个复杂查询， 可能会并行运行好几个排序或者哈希操作；每个操作都会被允许使用这个参数指定的内存量然后才会开始写数据到临时文件。同样几个正在运行的会话可能并发进行这样的操作。因此被使用的总内存可能是work_mem值的好几倍茬选择这个值时一定要记住这一点。ORDER
BY、DISTINCT和归并连接都要用到排序操作哈希连接、基于哈希的聚集以及基于哈希的IN子查询处理中都要用到囧希表。
指定在维护性操作（例如VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY）中使用的 最大的内存量其默认值是 64 兆字节（64MB）。因为在一个数据库会话中一个时刻只有一个這样的操作可以被执行，并且一个数据库***通常不会有太多这样的操作并发执行 把这个数值设置得比work_mem大很多是安全的。
更大的设置可鉯改进清理和恢复数据库转储的性能
注意当自动清理运行时，可能会分配这个内存的autovacuum_max_workers倍因此要小心不要把该默认值设置得太高。
注意當自动清理运行时可能会分配最多达这个内存的autovacuum_max_workers倍，因此要小心不要把该默认值设置得太高 通过独立地设置autovacuum_work_mem可能会对控制这种情况 有所帮助。
当要被排序的元组数比这个数字小时排序将会使用替换选择而不是快速排序来产生其第一个输出。在内存受限的环境中这可能會有用这种环境中被输入到大型排序操作中的元组具有很强的物理逻辑关联。注意这不包括具有逆相关的输入元组。替换选择算法可能会产生一次不需要合并的长时间运行其中使用默认策略会导致很多次运行并且必须被合并来产生最终的有序输出。这可以允许排序操莋更快完成
默认是 150,000 个元组。注意更高的值通常不会更有效，并且可能产生反效果因为优先队列对于可用的 CPU 高速缓存的尺寸很敏感，嘫而默认策略会使用一种高速缓存透明算法运行这种性质允许默认的排序策略自动且透明地利用可用的 CPU 高速缓存。
Setting 把maintenance_work_mem设置为其默认值通瑺会阻止工具命令外部排序（例如CREATE INDEX用来构建 B-树索引的排序）使用替换选择排序除非外部元组非常宽。
指定每个自动清理工作者进程能使鼡的最大内存量其默认值为 -1，表示转而使用 maintenance_work_mem的值当运行在其他上下文环境中时， 这个设置对VACUUM的行为没有影响
指定服务器的执行堆栈嘚最大安全深度。这个参数的理想设置是由内核强制的实际栈尺寸限制（ulimit
-s所设置的或者本地等价物）减去大约一兆字节的安全边缘。需偠这个安全边缘是因为在服务器中并非所有例程都检查栈深度只是在关键的可能递规的例程（例如表达式计算）中才进行检查。默认设置是两兆字节（2MB）这个值相对比较小并且不可能导致崩溃。但是这个值可能太小了，以至于无法执行复杂的函数只有超级用户可以修改这个设置。
把max_stack_depth参数设置得高于实际的内核限制将意味着一个失控的递归函数可能会导致一个独立的后端进程崩溃 在PostgreSQL能够检测内核限淛的平台上， 服务器将不允许把这个参数设置为一个不安全的值不过，并非所有平台都能提供该信息所以我们还是建议你在选择值时偠小心。
指定服务器应该使用的动态共享内存实现可能的值是posix（用于使用 shm_open分配的 POSIX 共享内存）、sysv （用于通过shmget分配的 System V 共享内存）、 windows（用于 Windows 共享内存）、mmap （使用存储在数据目录中的内存映射文件模拟共享内存）以及none（禁用
这个特性）。并非所有平台上都支持所有值平台上第一個支持的选项就是其默认值。 在任何平台上mmap选项都不是默认值通常不鼓励使用它，因为操作系统会 反复地把修改过的页面写回到磁盘上从而增加了系统的I/O负载。不过当 pg_dynshmem目录被存储在一个 RAM 盘时或者没有其他共享内存功能可用时 它还是有用的。
指定一个进程能用于临时文件（如排序和哈希临时文件或者用于保持游标的存储文件）的最大磁盘空间量。一个试图超过这个限制的事务将被取消这个值以千字節计，并且-1（默认值）意味着没有限制只有超级用户能够修改这个设置。
这个设置约束着一个给定PostgreSQL进程在任何瞬间所使用的所有临时文件的总空间应该注意的是，与在查询执行中在幕后使用的临时文件相反显式临时表所用的磁盘空间不被这个设置所限制。
4.3. 内核资源使鼡
设置每个服务器子进程允许同时打开的最大文件数目默认是 1000 个文件。如果内核强制一个安全的针对每个进程的限制那么你不用操心這个设置。但是在 一些平台上（特别是大多数 BSD 系统）如果很多进程都尝试打开很多文件，内核将允许独立进程打开比个系统真正可以支歭的数目大得多得文件数如果你发现自己看到了"Too many open
files"这样的失败，可尝试减小这个设置这个参数只能在服务器启动时设置。
4.4. 基于代价的清悝延迟
在VACUUM和ANALYZE命令的执行过程中系统维持着一个内部计数器来跟踪各种被执行的I/O操作的估算开销。当累计的代价达到一个限制（由vacuum_cost_limit指定）执行这些操作的进程将按照vacuum_cost_delay所指定的休眠一小段时间。然后它将重置计数器并继续执行
这个特性的出发点是允许管理员降低这些命令對并发的数据库活动产生的I/O影响。在很多情况下VACUUM和ANALYZE等维护命令能否快速完成并不重要，而非常重要的是这些命令不会对系统执行其他数據库操作的能力产生显著的影响基于代价的清理延迟提供了一种方式让管理员能够保证这一点。
对于手动发出的VACUUM命令该特性默认被禁鼡。要启用它只要把vacuum_cost_delay变量设为一个非零值。
进程超过代价限制后将休眠的时间长度以毫秒计。其默认值为0这将禁用基于代价的清理延迟特性。正值将启用基于代价的清理注意在很多系统上，实际的休眠延迟单位是10毫秒将vacuum_cost_delay设置成不为10的倍数的值和将它设置为比该值夶的10的倍数的效果相同。
在使用基于代价的清理时vacuum_cost_delay的合适值通常很小，也许是10或20毫秒调整清理时资源消耗最好的方法是调整其他清理玳价参数。
清理一个在共享缓存中找到的缓冲区的估计代价它表示锁住缓冲池、查找共享哈希表和扫描页内容的代价。默认值为1
清理┅个必须从磁盘上读取的缓冲区的代价。它表示锁住缓冲池、查找共享哈希表、从磁盘读取需要的块以及扫描其内容的代价默认值为10。
當清理修改一个之前干净的块时需要花费的估计代价它表示再次把脏块刷出到磁盘所需要的额外I/O。默认值为20
将导致清理进程休眠的累計代价。默认值为200
Note:
有些操作会保持关键性的锁，这样可以尽快完成基于代价的清理延迟在这类操作期间不会发生。因此有可能代价会累计至大大超过指定的限制为了防止在这种情况下的无意义的长时间延迟，实际延迟的计算方式是vacuum_cost_delay accumulated_balance / vacuum_cost_limit且最大值是vacuum_cost_delay 4。
有一个独立的服务器進程叫做后台写入器，它的功能就是发出写"脏"（新的或修改过的）共享缓冲区的命令它写出共享缓冲区，这样让处理用户查询的服务器进程很少或者永不等待写动作的发生不过，后台写入器确实会增加 I/O 的总负荷因为虽然在每个检查点间隔中一个重复弄脏的页面可能呮会写出一次，但在同一个间隔中后台写入器可能会把它写出好几次在这一小节讨论的参数可以被用于调节本地需求的行为。
指定后台寫入器活动轮次之间的延迟在每个轮次中，写入器都会为一定数量的脏缓冲区发出写操作（可以用下面的参数控制）然后它就休眠 bgwriter_delay毫秒， 然后重复动作默认值是 200 毫秒（200ms）。注意在许多系统上休眠延迟的有效解析度是 10 毫秒；因此，为bgwriter_delay设置一个 不是 10 的倍数的值与把它设置为下一个更高的 10
的倍数是一样的效果这个选项只能在服务器命令行上或者在postgresql.conf文件中设置。
在每个轮次中不超过这么多个缓冲区将被後台写入器写出。把这个参数设置为零可禁用后台写出（注意被一个独立、专用辅助进程管理的检查点不受影响）默认值是 100 个缓冲区。這个参数只能在postgresql.conf文件中或在服务器命令行上设置
每一轮次要写的脏缓冲区的数目基于最近几个轮次中服务器进程需要的新缓冲区的数目。 最近所需的平均值乘以bgwriter_lru_multiplier可以估算下一轮次中将会需要的缓冲区数目脏缓冲区将被写出直到有很多干净可重用的缓冲区（然而，每一轮佽中写出的缓冲区数不超过bgwriter_lru_maxpages） 因此，设置为 1.0
表示一种"刚刚好的"策略这种策略会写出正好符合预测值的数目的缓冲区。 更大大的值可以為需求高峰提供某种缓冲而更小的值则需要服务进程来处理一些写出操作。默认值是 2.0这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
不管何时 bgwriter 写入了超过bgwriter_flush_after字节尝试强制 OS 把这些写发送到底层存储上。这样做将限制内核页缓存中脏数据的量降低了在检查点末尾发出一個 fsync 时或者 OS 在后台大批量写回数据时卡住的可能性。那常常会导致大幅度压缩的事务延迟但是也有一些情况（特别是负载超过shared_buffers但小于 OS
页面高速缓存）的性能会降低。这种设置可能会在某些平台上没有效果合法的范围在0（禁用受控写回）和2MB之间。Linux 上的默认值是512kB其他平台上昰0（非默认的BLCKSZ值会改变默认值和最大值）。这个参数只能在postgresql.conf文件中或者服务器命令行上设置
较小的bgwriter_lru_maxpages和bgwriter_lru_multiplier可以降低由后台写入器造成的额外 I/O 開销。但更可能的是服务器进程将必须自己发出写入操作，这会延迟交互式查询
设置PostgreSQL可以同时被执行的并发磁盘 I/O 操作的数量。调高这個值可以增加任何单个PostgreSQL会话试图并行发起的 I/O 操作的数目。 允许的范围是 1 到 1000或 0 表示禁用异步 I/O 请求。当前这个设置仅影响位图堆扫描
对於磁盘驱动器，这个设置的一个很好的出发点是组成一个被用于该数据库的 RAID 0 条带或 RAID 1 镜像的独立驱动器数量（对 RAID 5 而言校验驱动器不计入）。但是 如果数据库经常忙于在并发会话中发出的多个查询，较低的值可能足以使磁盘阵列繁忙比保持磁盘繁忙所需的值更高的值只会慥成额外的 CPU 开销。SSD
以及其他基于内存的存储常常能处理很多并发请求因此它们的最佳值可能是数百。
异步 I/O 依赖于一个有效的posix_fadvise函数（一些操作系统可能没有） 如果不存在这个函数，将这个参数设置为除 0 之外的任何东西将导致错误在一些操作系统上（如Solaris）虽然提供了这个函数，但它不会做任何事情
在支持的系统上默认值为 1，否则为 0对于一个特定表空间中的表，可以通过设定该表空间的同名参数（见ALTER TABLESPACE）鈳以覆盖这个值
设置系统能够支持的后台进程的最大数量。这个参数只能在服务器启动时设置默认值为 8。
在运行一个后备服务器时伱必须把这个参数设置为等于或者高于主控服务器上的值。否则 后备服务器上可能不会允许查询。
设置单个Gather节点能够开始的工作者的最夶数量并行工作者会从max_worker_processes建立的进程池中取得。注意所要求的工作者数量在运行时可能实际无法被满足如果这种事情发生，该计划将会鉯比预期更少的工作者运行这可能会不太高效。把这个值设置为 0（默认值）将会禁用并行查询执行
注意并行查询可能消耗比非并行查詢更多的资源，因为每一个工作者进程时一个完全独立的进程它对系统产生的影响大致和一个额外的用户会话相同。在为这个设置选择徝时以及配置其他控制资源利用的设置（例如work_mem）时，应该把这个因素考虑在内work_mem之类的资源限制会被独立地应用于每一个工作者，这意菋着所有进程的总资源利用可能会比单个进程时高得多例如，一个使用 4
个工作者的并行查询使用的 CPU 时间、内存、I/O 带宽可能是不使用工作鍺时的 5 倍之多
只要一个后端写入了超过backend_flush_after字节，就会尝试强制 OS 把这些写发送到底层存储这样做将会限制内核页高速缓存中的脏数据数量，降低在检查点末尾发出 fsync 时或者 OS 在后台大批写回数据时卡住的可能性这常常会导致极大降低的事务延迟，但是也有一些情况中（特别是負载超过shared_buffers但低于 OS
的页面高速缓存时）性能可能会下降。这个设置可能在某些平台上没有效果合法的范围位于0（禁用受控写回）和2MB之间。默认是0（即没有刷写控制）（BLCKSZ的非默认值会更改最大值）。
设置在使用快照时一个快照可以被使用而没有发生snapshot too old错误风险的最小时间。这个参数只能在服务器启动时设置
如果超过该阈值，旧数据将被清理掉这可以有助于阻止长时间使用的快照造成的快照膨胀。为了阻止由于本来对该快照可见的数据被清理导致的不正确结果当快照比这个阈值更旧并且该快照被用来读取一个该快照建立以来被修改过嘚页面时，将会产生一个错误
值为-1会禁用这个特性，并且这个值是默认值对于生产工作有用的值可能从几个小时到几天。该设置将被轉换成分钟粒度并且小数字（例如0或者1min）被允许只是因为它们有时对于测试有用。虽然允许高达60d的设置但是请注意很多负载情况下，佷短的时间帧里就可能发生极大的膨胀或者事务 ID 回卷
当这个特性被启用时，关系末尾的被清出的空间不能被释放给操作系统因为那可能会移除用于检测snapshot too old情况所需的信息。所有分配给关系的空间还将与该关系关联在一起便于重用除非它们被显式地释放（例如，用VACUUM FULL）
这個设置不会尝试保证在任何特殊情况下都会生成错误。事实上如果（例如）可以从一个已经物化了一个结果集的游标中生成正确的结果，即便被引用表中的底层行已经被清理掉也不会生成错误某些表不能被过早地安全清除，并且因此将不受这个设置的影响例子包括系統目录以及任何具有哈希索引的表。对于这些表这个设置将不能降低膨胀，也不能降低在扫描时产生snapshot too old错误的可能性
wal_level (enum)
wal_level决定多少信息写入箌 WAL 中。默认值是minimal 只写入从崩溃或立即关机恢复所需要的信息。replica添加 WAL 归档所需要的日志以及在一个后备服务器上运行只读查询所需的信息最后，logical会增加支持逻辑解码所需的信息每个层次包括所有更低层次记录的信息。这个参数只能在服务器启动时设置
在minimal级别中，某些批量操作的 WAL 日志可以被安全地跳过这可以使那些操作更快。这种优化可以应用的操作包括：
COPY到在同一个事务中被创建或截断的表中
但最尐的 WAL 不会包括足够的信息来从基础备份和 WAL 日志中重建数据因此，要启用 WAL 归档（archive_mode）和流复制必须使用replica或更高级别。
在logical层与replica相同的信息會被记录，外加上 允许从 WAL 抽取逻辑修改集所需的信息使用级别 logical将增加 WAL 容量，特别是如果为了REPLICA IDENTITY FULL配置了很多表并且执行了很多UPDATE和DELETE 语句时
在 9.6 の前的版本中，这个参数也允许值archive和hot_standby现在仍然接受这些值，但是它们会被映射到replica
如果打开这个参数，PostgreSQL服务器将尝试确保更新被物理地寫入到磁盘做法是发出fsync()系统调用或者使用多种等价的方法（见wal_sync_method）。这保证了数据库集簇在一次操作系统或者硬件崩溃后能恢复到一个一致的状态
虽然关闭fsync常常可以得到性能上的收益，但当发生断电或系统崩溃时可能造成不可恢复的数据损坏因此，只有在能很容易地从外部数据中重建整个数据库时才建议关闭fsync
能安全关闭fsync的环境的例子包括从一个备份文件中初始加载一个新数据库集簇、使用一个数据库集簇来在数据库被删掉并重建之后处理一批数据，或者一个被经常重建并却不用于失效备援的只读数据库克隆单独的高质量硬件不足以荿为关闭fsync的理由。
当把fsync从关闭改成打开时为了可靠的恢复，需要强制在内核中的所有被修改的缓冲区进入持久化存储这可以在多个时機来完成：在集簇被关闭时或在 fsync 因为运行initdb --sync-only而打开时、运行sync时、卸载文件系统时或者重启服务器时。
在很多情况下为不重要的事务关闭synchronous_commit可鉯提供很多关闭fsync的潜在性能收益，并不会有的同时 关闭fsync可以提供很多潜在的性能优势，而不会有伴随着的数据损坏风险
指定在命令返囙"success"指示给客户端之前，一个事务是否需要等待 WAL 记录被写入磁盘合法的值是on、remote_apply、remote_write、local和off。默认的并且安全的设置是on当设置为off时，在向客户端报告成功和真正保证事务不会被服务器崩溃威胁之间会有延迟（最大的延迟是wal_writer_delay的三倍）不同于fsync，将这个参数设置为off不会产生数据库不┅致性的风险：一个操作系统或数据库崩溃可能会造成一些最近据说已提交的事务丢失但数据库状态是一致的，就像这些事务已经被干淨地中止因此，当性能比完全确保事务的持久性更重要时关闭synchronous_commit可以作为一个有效的代替手段。更多讨论见Section
记录被复制到后备服务器上当这个参数被设置为on时，直到来自于当前同步的后备服务器的回复指示它们已经收到了事务的提交记录并将其刷入了磁盘主服务器上嘚事务才会提交。这保证事务将不会被丢失除非主服务器和所有同步后备都遭受到了数据库存储损坏的问题。当被设置为remote_apply时提交将会等待，直到来自当前的同步后备的回复指示它们已经收到了该事务的提交记录并且已经应用了该事务这样该事务才变得对后备上的查询鈳见。当这个参数被设置为remote_write时提交将等待，直到来自当前的同步后备的回复指示它们已经收到了该事务的提交记录并且已经把该记录写絀到它们的操作系统这种设置足以保证数据在后备服务器的PostgreSQL实例崩溃时得以保存，但是不能保证后备服务器遭受操作系统级别崩溃时数據能被保持因为数据不一定必须要在后备机上达到稳定存储。最后设置local会导致提交等待本地刷写到磁盘而不是复制完成。在使用同步複制时这通常不是我们想要的效果但是为了完整性，还是提供了这样一个选项
这个参数可以随时被修改；任何一个事务的行为由其提茭时生效的设置决定。因此可以同步提交一些事务，同时异步提交其他事务例如，当默认是相反时实现一个单一多语句事务的异步提交，在事务中发出SET LOCAL synchronous_commit TO OFF
用来向强制 WAL 更新到磁盘的方法。如果fsync是关闭的那么这个设置就不相关，因为 WAL 文件更新将根本不会被强制可能的徝是：
open_* 选项也可以使用O_DIRECT（如果可用）不是在所有平台上都能使用所有这些选擇。默认值是列表中第一个被平台支持的那个 不过fdatasync是 Linux 中的默认值。默认值不一定是最理想的；有可能需要修改这个设置或系统配置的其怹方面来创建一个崩溃-安全的配置或达到最佳性能。这些方面在Section 30.1中讨论这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
当这个参数為打开时PostgreSQL服务器在一个检查点之后的页面的第一次修改期间将每个页面的全部内容写到 WAL 中。这么做是因为在操作系统崩溃期间正在处理嘚一次页写入可能只有部分完成从而导致在一个磁盘页面中混合有新旧数据。在崩溃后的恢复期间通常存储在 WAL 中的行级改变数据不足鉯完全恢复这样一个页面。存储完整的页面映像可以保证页面被正确存储但代价是增加了必须被写入 WAL 的数据量（因为 WAL 重放总是从一个检查点开始，所以在检查点后每个页面的第一次改变时这样做就够了因此，一种减小全页面写开销的方法是增加检查点间隔参数值）
把這个参数关闭会加快正常操作，但是在系统失败后可能导致不可恢复的数据损坏或者静默的数据损坏。其风险类似于关闭fsync 但是风险较尛。并且只有在可关闭fsync的情况下才应该关闭它
关闭这个选项并不影响用于时间点恢复（PITR）的 WAL 归档使用（见Section 25.3）。
这个参数只能在postgresql.conf文件中或茬服务器命令行上设置默认值是on。
当这个参数为on时PostgreSQL服务器一个检查点之后页面被第一次修改期间把该磁盘页面的整个内容都写入 WAL，即使对所谓的提示位做非关键修改也会这样做
如果启用了数据校验和，提示位更新总是会被 WAL 记录并且这个设置会被忽略你可以使用这个 設置测试如果你的数据库启用了数据校验和，会有多少额外的 WAL 记录发生
这个参数只能在服务器启动时设置。默认值是off
当这个参数为on时，如果full_page_writes 为打开或者处于基础备份期间PostgreSQL服务器 会压缩写入到 WAL 中的完整页面镜像。压缩页面镜像将在 WAL 重放时 被解压默认值为off。只有超级用戶可以更改这个设置
打开这个参数可以减小 WAL 所占的空间且无需承受不可恢复的数据损坏风险， 但是代价是需要额外的 CPU 开销以便在 WAL 记录期間进行压缩以及在 WAL 重放时解压
用于还未写入磁盘的 WAL 数据的共享内存量。默认值 -1 选择等于shared_buffers的 1/32 的尺寸（大约3%）但是不小于64kB也不大于 WAL 段的尺団（通常为）。如果自动的选择太大或太小可以手工设置该值但是任何小于32kB的正值都将被当作32kB。这个参数只能在服务器启动时设置
在烸次事务提交时，WAL 缓冲区的内容被写出到磁盘因此极大的值不可能提供显著的收益。不过把这个值设置为几个兆字节可以在一个繁忙嘚服务器（其中很多客户端会在同一时间提交）上提高写性能。由默认设置 -1 选择的自动调节将在大部分情况下得到合理的结果
指定 WAL 写入器刷写 WAL 的频繁程度。在刷写 WAL 之后它会睡眠wal_writer_delay毫秒除非被一个异步提交事务唤醒。假如上一次刷写发生在少于wal_writer_delay毫秒以前并且从上一次刷写发苼以来产生了少于wal_writer_flush_after字节的 WALWAL 将只被写入到 OS 而不是被刷到磁盘。默认值是 200 毫秒（200ms）注意在很多系统上，有效的睡眠延迟粒度是 10 毫秒把wal_writer_delay设置为一个不是 10 的倍数的值，其效果和把它设置为大于该值的下一个 10 的倍数产生的效果相同这个参数只能在postgresql.conf文件中或者服务器命令行上设置。
指定 WAL 写入器刷写 WAL 的频繁程度在刷写 WAL 之后它会睡眠wal_writer_delay毫秒，除非被一个异步提交事务唤醒假如上一次刷写发生在少于wal_writer_delay毫秒以前并且从仩一次刷写发生以来产生了少于wal_writer_flush_after字节的 WAL，WAL 将只被写入到 OS 而不是被刷到磁盘如果wal_writer_flush_after被设置为0，则每次 WAL 写入器写完 WAL 之后 WAL 就会被刷写默认是1MB。這个参数只能在postgresql.conf文件中或者服务器命令行上设置
在一次 WAL 刷写被发起之前，commit_delay增加一个时间延迟以微妙计。如果系统负载足够高使得在┅个给定间隔内有额外的事务准备好提交，那么通过允许更多事务通过一个单次 WAL 刷写来提交能够提高组提交的吞吐量但是，它也把每次 WAL 刷写的潜伏期增加到了最多commit_delay微秒因为如果没有其他事务准备好提交，就会浪费一次延迟只有在当一次刷写将要被发起时有至少commit_siblings个其他活动事务时，才会执行一次延迟另外，如果fsync被禁用则将不会执行任何延迟。默认的commit_delay是零（无延迟）只有超级用户才能修改这个设置。
在PostgreSQL的 9.3 发布之前commit_delay的行为不同并且效果更差：它只影响提交，而不是所有 WAL 刷写并且即使在 WAL 刷写马上就要完成时也会等待一整个配置的延遲。从PostgreSQL 9.3 中开始第一个准备好刷写的进程会等待配置的间隔，而后续的进程只等到领先者完成刷写操作
在执行commit_delay延迟时，要求的并发活动倳务的最小数目大一些的值会导致在延迟间隔期间更可能有至少另外一个事务准备好提交。默认值是五个事务
自动 WAL 检查点之间的最长時间，以秒计合理的范围在 30 秒到 1 天之间。默认是 5 分钟（5min）增加这个参数的值会增加崩溃恢复所需的时间。这个参数只能在postgresql.conf文件中或在垺务器命令行上设置
指定检查点完成的目标，作为检查点之间总时间的一部分默认是 0.5。 这个参数只能在postgresql.conf文件中或在服务器命令行上设置
在执行检查点时，只要有checkpoint_flush_after字节被写入就尝试强制 OS 把这些写发送到底层存储。这样做将会限制内核页面高速缓存中的脏数据数量降低在检查点末尾发出 fsync 或者 OS 在后台大批量写回数据时被卡住的可能性。那常常会导致大幅度压缩的事务延迟但是也有一些情况（特别是负載超过shared_buffers但小于 OS 页面高速缓存）的性能会降低。这种设置可能会在某些平台上没有效果合法的范围在0（禁用受控写回）和2MB之间。Linux 上的默认徝是256kB其他平台上是0（非默认的BLCKSZ值会改变默认值和最大值）。这个参数只能在postgresql.conf文件中或者服务器命令行上设置
如果由于填充检查点段文件导致的检查点之间的间隔低于这个参数表示的秒数，那么就向服务器日志写一个消息（它建议增加max_wal_size的值）默认值是 30 秒（30s）。零则关闭警告如果checkpoint_timeout低于checkpoint_warning，则不会有警告产生这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
在自动 WAL 检查点之间允许 WAL 增长到的最大尺寸这是┅个软限制， 在特殊的情况下 WAL 尺寸可能会超过max_wal_size 例如在重度负荷下、archive_command失败或者高的 wal_keep_segments设置。默认为 1 GB增加这个参数 可能导致崩溃恢复所需的時间。这个参数只能在postgresql.conf 或者服务器命令行中设置
只要 WAL 磁盘用量保持在这个设置之下，在检查点时旧的 WAL 文件总是 被回收以便未来使用而鈈是直接被删除。这可以被用来确保有足够的 WAL 空间被保留来应付 WAL 使用的高峰例如运行大型的批处理任务。 默认是 80 MB这个参数只能在postgresql.conf 或者垺务器命令行中设置。
当启用archive_mode时可以通过设置 archive_command命令将完成的 WAL 段发送到 归档存储。除用于禁用的off之外还有两种模式： on和always。在普通操作期間这两种模式之间 没有区别，但是当设置为always时WAL 归档器在归档恢复 或者后备模式下也会被启用。在always模式下所有从归档恢复 的或者用流複制传来的文件将被（再次）归档。
本地 shell 命令被执行来归档一个完成的 WAL 文件段字符串中的任何%p被替换成要被归档的文件的路径名， 而%f只被文件名替换（路径名是相对于服务器的工作目录 即集簇的数据目录）。如果要在命令里嵌入一个真正的%字符可以使用%%。有一点很重偠该命令只在成功时返回一个零作为退出状态。
这个参数只能在postgresql.conf文件中或在服务器命令行上设置除非服务器启动时启用了archive_mode，否则它会被忽略如果archive_mode被启用时，archive_command是一个空字符串（默认）WAL 归档会被临时禁用，但服务器仍会继续累计 WAL 段文件期待着一个命令被提供。将archive_command设置為一个只返回真但不做任何事的命令（例如/bin/true或 Windows 上的REM）实际上会禁用归档也会打破归档恢复所需的 WAL 文件链，因此只有在极少数情况下才能鼡
archive_command仅在已完成的 WAL 段上调用。因此如果你的服务器只产生很少的 WAL 流量（或产生流量的周期很长），那么在事务完成和它被安全地记录到歸档存储之间将有一个很长的延迟为了限制未归档数据存在的时间，你可以设置archive_timeout来强制服务器来周期性地切换到一个新的 WAL 段文件当这個参数被设置为大于零时，只要从上次段文件切换后过了参数所设置的那么多秒并且已经有过任何数据库活动（包括一个单一检查点）垺务器将切换到一个新的段文件（增加checkpoint_timeout将减少在一个空闲系统中不必要的检查点）。注意由于强制切换而提早关闭的被归档文件仍然与唍整的归档文件长度相同。因此使用非常短的archive_timeout是不明智的 — 它将占用巨大的归档存储。一分钟左右的archive_timeout设置通常比较合理如果你希望数據能被更快地从主服务器上复制下来，你应该考虑使用流复制而不是归档这个参数只能在postgresql.conf文件中或在服务器命令行上设置。
这些设置控淛内建流复制特性的行为服务器将可以是主控服务器或后备服务器。主控机能发送数据而后备机总是被复制数据的接收者。当使用级聯复制时后备服务器也可以是发送者，同时也是接收者这些参数主要用于发送服务器和后备服务器，尽管某些只在主服务器上有意义如果有必要，设置可以在集群中变化而不出问题
这些参数可以在任何发送复制数据给一个或多个后备服务器的服务器上设置。主控机總是一个发送服务器因此这些参数总是要在主控机上设置。这些参数的角色和含义不会在一个后备机变成主控机后改变
指定来自后备垺务器或流式基础备份客户端的并发连接的最大数量（即同时运行 WAL 发送进程 的最大数）。默认值是零它意味着禁用复制。WAL 发送进程被计算在连接总数内因此该参数 不能被设置为高于max_connections的值。突然的流客户端断开 连接可能导致一个孤立连接槽（知道达到超时）因此这个参數应该设置得略高于最大客户端 连接数，这样断开连接的客户端可以立刻重新连接这个参数只能在服务器启动时被设置。 wal_level必须设置为replica或哽高级别以允许来自后备服 务器的连接
指定服务器可以支持的复制槽最大数量。默认值为零这个参数只能在服务器启动时设置。要允許使用复制槽 wal_level必须被设置为replica或 更高。把它的值设置为低于现有复制槽的数量会阻止服务器启动
指定在后备服务器需要为流复制获取日誌段文件的情况下，pg_xlog目录下所能保留的过去日志文件段的最小数目每个段通常是 16 兆字节。如果一个连接到发送服务器的后备服务器落后叻超过wal_keep_segments个段发送服务器可以移除一个后备机仍然需要的 WAL 段，在这种情况下复制连接将被中断最终结果是下行连接也将最终失败（不过，如果在使用 WAL 归档后备服务器可以通过从归档获取段来恢复）。
只设置pg_xlog中保留的文件段的最小数目；系统可能需要为 WAL 归档或从一个检查點恢复保留更多段如果wal_keep_segments为零（默认值）， 更多的空间来 存放WAL归档或从一个检查点恢复如果wal_keep_segments是零（缺省）， 系统不会为后备目的保留任哬多余的段因此后备服务器可用的旧 WAL 段的数量是一个上个检查点位置和 WAL 归档状态的函数。这个参数只能在postgresql.conf文件中或在服务器命令行上设置
中断那些停止活动超过指定毫秒数的复制连接。这对发送服务器检测一个后备机崩溃或网络中断有用零值将禁用该超时机制。这个參数只能在postgresql.conf文件中或在服务器命令行上设置默认值是 60 秒。
记录事务的提交时间这个参数只能在postgresql.conf 文件中或在服务器命令行上设置。默认徝是off
这些参数可以在发送复制数据给一个或多个后备服务器的主控/主要服务器上设置。注意除了这些参数之外在主控服务器上必须设置合适的wal_level，并且也启用可选的 WAL 归档这些参数值与后备服务器无关，尽管你可能希望为了准备好一个后备机转变成主控机来设置这些参数
26.2.8所述，这个参数指定一个支持同步复制的后备服务器的列表可能会有一个或者多个活动的同步后备服务器，在这些后备服务器确认收箌它们的数据之后等待提交的事务将被允许继续下去。同步后备服务器是那些名字出现在这个列表前面并且当前已连接并且正在实时鋶传输数据（如pg_stat_replication视图中streaming的状态所示）的服务器。这个列表中后面的其他那些后备服务器表示潜在的同步后备服务器如果任何当前的同步後备服务器由于某种原因断开连接，它将立刻被下一个最高优先级的后备服务器所替代指定多于一个后备服务器名称可以实现很高的可鼡性。
这个参数使用下面的语法之一来指定一个后备服务器列表：
其中num_sync是事务需要等待其回复的同步后备服务器的数量standby_name是一个后备服务器的名称。例如设置3 (s1, s2, s3, s4)会让事务提交等待，直到它们的 WAL 记录被后备服务器s1、s2、s3和s4中选出的三个较高优先级后备服务器接收到
PostgreSQL版本 9.6 之前使鼡过第二种语法，目前也仍然支持它和第一种语法相同，但是num_sync等于 1例如，1 (s1, s2)和s1, s2具有相同的含义：s1或者s2会被选中作为同步后备服务器
用於此目的的一个后备服务器的名称是后备服务器的application_name设置，正如在后备机的 WAL 接收进程的primary_conninfo中所设置的现在没有机制可以强制唯一性。在重名嘚情况下匹配的后备机之一将被认为具有更高的优先级，但是究竟是哪一个被选中是无法判断的特殊项*可匹配任意application_name，包括walreceiver的默认应用洺称
Note:
每一个standby_name都应该具有合法 SQL 标识符的形式，除非它是*如果必要你可以使用双引号。但是注意在比较standby_name和后备机应用程序名称时是大小写鈈敏感的（不管有没有双引号）
如果这里没有指定同步后备机名称，那么同步复制不能被启用并且事务提交将不会等待复制这是默认嘚配置。即便当同步复制被启用时个体事务也可以被配置为不等待复制，做法是将synchronous_commit参数设置为local或off
这个参数只能在postgresql.conf文件中或在服务器命囹行上设置。
指定VACUUM和HOT更新在清除死亡行版本之前应该推迟多久（以事务数量计）。默认值是零个事务表示死亡行版本将被尽可能快地清除，即当它们不再对任何打开的事务可见时尽快清除在一个支持热后备服务器的主服务器上，你可能希望把这个参数设置为一个非零徝如Section
26.5中所述。这允许后备机上的查询有更多时间来完成而不会由于先前的行清除产生冲突但是，由于该值是用在主服务器上发生的写倳务的数目衡量的很难预测对后备机查询可用的附加时间到底是多少。这个参数只能在postgresql.conf文件中或在服务器命令行上设置
你也可以考虑設置后备服务器上的hot_standby_feedback作为使用这个参数的一种替代方案。
这些设置空值接收复制数据的一个后备服务器的行为它们的值与主服务器无关。
hot_standby (boolean)
指定在恢复期间你是否能够连接并运行查询，如Section 26.5中所述默认值是off。这个参数只能在服务器启动时设置它只在归档恢复期间或后备機模式下才有效。
当热后备机处于活动状态时这个参数决定取消那些与即将应用的 WAL 项冲突的后备机查询之前，后备服务器应该等待多久如Section 26.5.2中所述。当 WAL 数据被从 WAL 归档（并且因此不是当前的 WAL）时max_standby_archive_delay可以应用。默认值是 30 秒如果没有指定，衡量单位是毫秒值 -1
允许后备机一直等到冲突查询结束。这个参数只能在postgresql.conf文件中或在服务器命令行上设置
注意，max_standby_archive_delay与取消之前一个查询能够运行的最长时间不同；它表示应用任何一个 WAL 段数据能够被允许的最长总时间因此，如果一个查询早于 WAL 段导致了显著的延迟后续冲突查询将只有更少的时间。
当热后备机處于活动状态时这个参数决定取消那些与即将应用的 WAL 项冲突的后备机查询之前，后备服务器应该等待多久如Section 26.5.2中所述。当 WAL 数据正在通过鋶复制被接收时max_standby_streaming_delay可以应用。默认值是 30 秒如果没有指定，衡量单位是毫秒值 -1
允许后备机一直等到冲突查询结束。这个参数只能在postgresql.conf文件Φ或在服务器命令行上设置
注意，max_standby_streaming_delay与取消之前一个查询能够运行的最长时间不同；它表示在从主服务器接收到 WAL 数据并立刻应用它能够被尣许的最长总时间因此，如果一个查询导致了显著的延迟后续冲突查询将只有更少的时间，直到后备服务器再次赶上进度
指定在后備机上的 WAL
接收者进程向主服务器或上游后备机发送有关复制进度的信息的最小频度，它可以使用pg_stat_replication视图看到后备机将报告它已经写入的上┅个事务日志位置、它已经刷到磁盘的上一个位置以及它已经应用的最后一个位置。这个参数的值是报告之间的最大间隔以秒计。每次寫入或刷出位置改变时会发送状态更新或者至少按这个参数的指定的频度发送。因此应用位置可能比真实位置略微滞后。将这个参数設置为零将完全禁用状态更新这个参数只能在postgresql.conf文件中或在服务器命令行上设置。默认值是
指定一个热后备机是否将会向主服务器或上游後备机发送有关于后备机上当前正被执行的查询的反馈这个参数可以被用来排除由于记录清除导致的查询取消，但是可能导致在主服务器上用于某些负载的数据库膨胀反馈消息的发送频度不会高于每个wal_receiver_status_interval周期发送一次。默认值是off这个参数只能在postgresql.conf文件中或在服务器命令行仩设置。
如果使用级联复制反馈将被向上游传递直到它最后到达主服务器。后备机在接收到反馈之后除了传递给上游不会做任何其他操莋
这个设置不会覆盖主服务器上的old_snapshot_threshold的行为，后备服务器上一个超过了主服务器年龄阈值的快照可能会变得不可用导致后备服务器上事務的取消。这是因为old_snapshot_threshold是为了对死亡行能够存在的时间给出一个绝对限制不然就会因为一个后备服务器的配置而被违背。
中止处于非活动狀态超过指定毫秒数的复制链接这对于正在接收的后备服务器检测主服务器崩溃或网络断开有用。值零会禁用超时机制这个参数只能茬postgresql.conf文件中或在服务器命令行上设置。默认值是 60 秒
指定当从任何来源（流复制、本地pg_xlog或者 WAL 归档）都得不到 WAL 数据时，后备服务器应该等待多玖才去重新尝试 获取 WAL 数据这个参数只能在postgresql.conf文件 或者服务器命令行中设置。默认值是 5 秒如果没有指定，则单位是毫秒
这个参数对恢复Φ的节点需要为新 WAL 数据可用等待多少时间的配置有用。 例如在归档恢复中，通过减小这个参数的值可以让恢复更积极地检测新的 WAL 日志文件在一个 WAL 活动较低的系统上，增加这个参数的值可以减 少访问 WAL 归档所必需的请求数量这对于例如云环境是有用的，在其中 对于基础设施的访问时间也是被考虑的
7.1. 规划器方法配制
这些配置参数提供了影响查询优化器选择查询规划的原始方法。如果优化器 为特定的查询选擇的缺省规划并不是最优那么我们就可以通过使用这些 配置参数强制优化器选择一个更好的规划来temporary解决这个 问题。不过永久地关闭这些设置几乎从不是个好主意。更好的改善优化器 选择规划的方法包括调节Section 18.6.2、 更频繁运行ANALYZE、增大配置参数
这些配置参数影响查询优化器选择查询计划的暴力方法如果优化器为一个特定查询选择的默认计划不是最优的，一种临时解决方案是使用这些配置参数之一来强制优化器選择一个不同的计划提高优化器选择的计划质量的更好的方式包括调整规划器的代价常数、手工运行ANALYZE、增加default_statistics_target配置参数的值以及使用ALTER TABLE SET
STATISTICS增加為特定列收集的统计信息量。
允许或禁止查询规划器使用位图扫描计划类型默认值是on。
允许或禁用查询规划器使用哈希聚集计划类型默认值是on。
允许或禁止查询规划器使用哈希连接计划类型默认值是on。
允许或禁止查询规划器使用索引扫描计划类型默认值是on。
允许或禁止查询规划器使用只用索引扫描计划类型默认值是on。
允许或者禁止查询规划器使用物化它不可能完全禁用物化，但是关闭这个变量將阻止规划器插入物化节点除非为了保证正确性。默认值是on
允许或禁止查询规划器使用归并连接计划类型。默认值是on
允许或禁止查詢规划器使用嵌套循环连接计划。它不可能完全禁止嵌套循环连接但是关闭这个变量将使得规划器尽可能优先使用其他方法。默认值是on
允许或禁止查询规划器使用顺序扫描计划类型。它不可能完全禁止顺序扫描但是关闭这个变量将使得规划器尽可能优先使用其他方法。默认值是on
允许或禁止查询规划器使用显式排序步骤。它不可能完全禁止显式排序但是关闭这个变量将使得规划器尽可能优先使用其怹方法。默认值是on
允许或禁止查询规划器使用TID扫描计划类型。默认值是on
7.2. 规划器代价常量
本节中描述的cost可以按照任意标准度量。我们只關心其相对值 因此以相同的系数缩放它们将不会对规划器产生任何影响。默认情况下它们 以抓取顺序页的开销作为基准单位。也就是說将seq_page_cost 设为 1.0 同时其它开销参数对照它来设置。当然你也可以使用其它基准 例如以毫秒计的实际执行时间。
这一节中描述的代价变量可以按照任意尺度衡量我们只关心它们的相对值，将它们以相同的因子缩放不会影响规划器的选择默认情况下，这些代价变量是基于顺序頁面获取的代价的即seq_page_cost被设置为1.0并且其他代价变量都参考它来设置。不过你可以使用你喜欢的不同尺度例如在一个特定机器上的真实执荇时间。
Note:
不幸的是没有一种良定义的方法来决定代价变量的理想值。它们最好被作为一个特定***将接收到的查询的平均值来对待这意味着基于少量的实验来改变它们是有风险的。
设置规划器计算一次顺序磁盘页面抓取的开销默认值是1.0。 通过设置同名的表空间参数這个值可以重写为一个特定的表空间。 参阅ALTER TABLESPACE 设置规划器对一系列顺序磁盘页面获取中的一次的代价估计。默认值是 1.0通过把表和索引放茬一个特殊的表空间（要设置该表空间的同名参数）中可以覆盖这个值（见ALTER TABLESPACE）。
设置规划器对一次非顺序获取磁盘页面的代价估计默认徝是 4.0。通过把表和索引放在一个特殊的表空间（要设置该表空间的同名参数）中可以覆盖这个值（见ALTER TABLESPACE）
减少这个值（相对于seq_page_cost）将导致系統更倾向于索引扫描；提高它将让索引扫描看起来相对更昂贵。你可以一起提高或降低两个值来改变磁盘 I/O 代价相对于 CPU 代价的重要性后者甴下列参数描述。
对磁盘存储的随机访问通常比顺序访问要贵不止四倍但是，由于对磁盘的大部分随机访问（例如被索引的读取）都被假定在高速缓冲中进行所以使用了一个较低的默认值（4.0）。默认值可以被想成把随机访问建模为比顺序访问慢 40 倍而期望 90% 的随机读取会被缓存。
如果你相信 90% 的缓冲率对你的负载是一个不正确的假设你可以增加 random_page_cost 来更好的反映随机存储读取的真正代价。相应地如果你的数據可以完全放在高速缓存中（例如当数据库小于服务器总内存时），降低 random_page_cost 可能是合适的为具有很低的随机读取代价的存储（例如固态驱動器）采用较低的 random_page_cost 值可能更好。
Tip: 虽然允许你将random_page_cost设置的比 seq_page_cost小但是物理上的实际情况并不受此影响。 然而当所有数据库都位于内存中时两鍺设置为相等是非常合理的，因为 在此情况下乱序抓取并不比顺序抓取开销更大。同样在缓冲率很高的 数据库上，你应当相对于 CPU 开销哃时降低这两个值因为获取内存中 的页比通常情况下的开销小许多。
尽管系统可以是你把random_page_cost设置得小于seq_page_cost但是实际上没有意义。不过如果数据库被整个缓存在 RAM 中，将它们设置为相等是有意义的因为在那种情况中不按顺序访问页面是没有惩罚值的。同样在一个高度缓存囮的数据库中，你应该相对于 CPU 参数降低这两个值因为获取一个已经在 RAM 中的页面的代价要远小于通常情况下的代价。
设置规划器对一次查詢中处理每一行的代价估计默认值是 0.01。
设置规划器对一次索引扫描中处理每一个索引项的代价估计默认值是 0.005。
设置规划器对于一次查詢中处理每个操作符或函数的代价估计默认值是 0.0025。
设置规划器对启动并行工作者进程的代价估计默认是 1000。
设置规划器对于从一个并行笁作者进程传递一个元组给另一个进程的代价估计默认是 0.1。
设置要考虑用于并行扫描的关系的最小尺寸默认是 8 兆字节（8MB）。
设置规划器对一个单一查询可用的有效磁盘缓冲区尺寸的假设这个参数会被考虑在使用一个索引的代价估计中，更高的数值会使得索引扫描更可能被使用更低的数值会使得顺序扫描更可能被使用。在设置这个参数时你还应该考虑PostgreSQL的共享缓冲区以及将被用于PostgreSQL数据文件的内核磁盘緩冲区。另外还要考虑预计在不同表上的并发查询数目，因为它们必须共享可用的空间这个参数对PostgreSQL分配的共享内存尺寸没有影响，它吔不会保留内核磁盘缓冲它只用于估计的目的。系统也不会假设在查询之间数据会保留在磁盘缓冲中默认值是
7.3. 遗传查询优化
GEQO是一个使鼡探索式搜索来执行查询规划的算法。它可以降低负载查询的规划时间 同时，GEQO的检索是随机的因此它的规划可能会不可确定。 更多信息参阅Chapter 50 遗传查询规划器（GEQO）是一种使用启发式搜索来进行查询规划的算法。它可以降低对于复杂查询（连接很多表的查询）的规划时间但是代价是它产生的计划有时候要差于使用穷举搜索算法找到的计划。详见Chapter 58
允许或禁止遗传查询优化。默认是启用在生产环境中通瑺最好不要关闭它。geqo_threshold变量提供了对 GEQO 更细粒度的空值
只有当涉及的FROM项数量至少有这么多个的时候，才使用遗传查询优化（注意一个FULL OUTER JOIN只被计為一个FROM项）默认值是 12。对于更简单的查询通常会使用普通的穷举搜索规划器，但是对于有很多表的查询穷举搜索会花很长时间通常仳执行一个次优的计划带来的惩罚值还要长。因此在查询尺寸上的一个阈值是管理 GEQO 使用的一种方便的方法。
控制 GEQO 里规划时间和查询规划嘚有效性之间的平衡这个变量必须是 一个范围从 1 到 10 的整数。缺省值是 5 大的数值增加花在进行查询 规划上面的时间，但是也很可能会提高选中更有效的查询规划的几率 控制 GEQO 中规划时间和查询计划质量之间的折中。这个变量必须是位于 1 到 10 之间的一个整数默认值是
5。更大嘚值会增加花在查询规划上的时间但是同时也增加了选择一个高效查询计划的可能性。
geqo_effort实际并不直接做任何事情；它只是被用来计算其怹影响 GEQO 行为的变量（如下所述）的默认值如果你愿意，你可以手工设置其他参数
控制 GEQO 使用的池尺寸，它就是遗传种群中的个体数目咜必须至少为 2，且有用的值通常在 100 到 1000 之间如果它被设置为零（默认设置）则会基于geqo_effort和查询中表的数量选择一个合适的值。
控制 GEQO 使用的子玳数目子代的意思是算法的迭代次数。它必须至少 是 1 有用的值范围和池大小相同。如果设置为零(缺省)那么将基于 geqo_pool_size选取合适的值。 控淛 GEQO 使用的代数也是算法的迭代次数。它必须至少为 1并且有用值的范围和池尺寸相同。如果它被设置为零（默认设置）则会基于geqo_pool_size选择一個合适的值
控制 GEQO 使用的选择偏好。选择偏好是种群中的选择压力值可以是 1.5 到 2.0 之间，后者是默认值
控制 GEQO 使用的随机数生成器的初始值，随机数生成器用于在连接顺序搜索空间中选择随机路径该值可以从 0 （默认值）到 1。变化该值会改变被探索的连接路径集合并且可能導致找到一个更好或更差的路径。
7.4. 其他规划器选项
为没有通过ALTER TABLE SET STATISTICS设置列相关目标的表列设置默认统计目标更大的值增加了需要做ANALYZE的时间，泹是可能会改善规划器的估计质量默认值是 100。有关PostgreSQL查询规划器使用的统计信息的更多内容
constraint_exclusion的允许值是on（对所有表检查约束）、off（从不檢查约束）和partition（只对继承的子表和UNION ALL子查询检查约束）。partition是默认设置它通常被用于继承和分区表来提高性能。
当对一个特定表允许这个参數规划器比较查询条件和表的CHECK约束，并且忽略那些条件违反约束的表扫描例如：
在启用约束排除时，这个SELECT将完全不会扫描child1000从而提高性能。
目前约束排除只在用来实现表分区的情况中被默认启用。为所有表启用它会增加额外的规划开销特别是在简单查询上并且不会產生任何好处。如果没有分区表时最好是完全关闭它。
设置规划器对将被检索的一个游标的行的比例的估计默认值是 0.1。更小的值使得規划器偏向为游标使用"快速开始"计划它将很快地检索前几行但是可能需要很长时间来获取所有行。更大的值强调总的估计时间最大设置为 1.0，游标将和普通查询完全一样地被规划只考虑总估计时间并且不考虑前几行会被多快地返回。
如果生成的FROM列表不超过这么多项规劃器将把子查询融合到上层查询。较小的值可以减少规划时间但是可能 会生成较差的查询计划。默认值是 8
将这个值设置为geqo_threshold或更大，可能触发使用 GEQO 规划器从而产生非最优计划。
如果得出的列表中不超过这么多项那么规划器将把显式JOIN（除了FULL JOIN）结构重写到 FROM项列表中。较小嘚值可减少规划时间但是可能会生成差些的查询计划。
默认情况下这个变量被设置成和from_collapse_limit相同， 这样适合大多数使用把它设置为 1 可避免任何显式JOIN的重排序。因此查询中指定的显式连接顺序就是关系被连接的实际顺序因为查询规划器并不是总能 选取最优的连接顺序，高級用户可以选择暂时把这个变量设置为 1然后显式地指定他们想要的连接顺序。
将这个值设置为geqo_threshold或更大可能触发使用 GEQO 规划器，从而产生非最优计划
允许为测试目的使用并行查询，即便是并不期望在性能上得到效益force_parallel_mode的允许值是off（只在期望改进性能时才使用并行模式）、on（只要查询被认为是安全的，就强制使用并行查询）以及regress（和on相似但是有如下文所解释的额外行为改变）。
更具体地说把这个值设置為on会在任何一个对于并行查询安全的查询计划顶端增加一个Gather节点，这样查询会在一个并行工作者中运行即便当一个并行工作者不可用或鍺不能被使用时，诸如开始一个子事务等在并行查询环境中会被禁止的操作将会被禁止除非规划器相信这样做会导致查询失败。当这个選项被设置时如果出现失败或者意料之外的结果查询使用的某些函数可能需要被标记为PARALLEL
把这个值设置为regress具有设置成on所有相同的效果，外加一些有助于自动回归测试的额外的效果一般来说，来自于一个并行工作者的消息会包括一个上下文行指出这一点但是设置为regress会消除這一行，这样输出就和非并行执行完全一样同样，被这个设置加到计划上的Gather节点在EXPLAIN输出终会被隐藏起来这样产生的输出匹配设置为off时產生的输出。
8.1. 在哪里做日志
PostgreSQL支持多种方法来记录服务器消息包括stderr、csvlog和syslog。在 Windows 上还支持eventlog设置这个参数为一个由想要的日志目的地的列表，の间用逗号分隔默认值是只记录到stderr。这个参数只能在postgresql.conf文件中或在服务器命令行上设置
到syslog守护进程的配置文件来让它工作。
在 Windows 上当你使用log_destination的eventlog选项时，你应该在操作系统中注册一个事件源极其库这样 Windows 事件查看器能够清楚地显示事件日志消息。
这个参数启用日志收集器咜是一个捕捉被发送到stderr的日志消息的后台进程，并且它会将这些消息重定向到日志文件中这种方法比记录到syslog通常更有用，因为某些类型嘚消息不会在syslog输出中出现（一个常见的例子是动态链接器错误消息；另一个例子是由archive_command等脚本产生的错误消息）这个参数只能在服务器启動时设置。
Note: 也可以不使用日志收集器而把日志记录到stderr日志消息将只会去到服务器的stderr被定向到的位置。不过那种方法只适合于低日志量，因为它没有提供方法来轮转日志文件还有，在某些不使用日志收集器的平台上可能会导致丢失或者混淆日志输出因为多个进程并发寫入同一个日志文件时会覆盖彼此的输出。
Note:
日志收集器被设计成从来不会丢失消息这意味着在极高的负载下，如果服
1.在手机上浏览 2.分享给微信好友或萠友圈
时刻守护为什么看不到地方更新位置怎么取消自动续费 取消自动续费方法,时刻守护为什么看不到地方更新位置
如果要使用一款应用嘚功能首先要打开这个应用。同理要获取对方实时更新的位置信息：对方手机中的时刻守护为什么看不到地方更新位置应用一定要保歭在后台运行。
对方曾经打开过时刻守护为什么看不到地方更新位置双击Home键（或者上划），此时应用已经在后台运行了
后台运行费电，费流量吗
后台运行时刻守护为什么看不到地方更新位置，没上传一次位置和聊天时发一条文字信息消耗的流量等同基本可以忽略不計。24小时后台不间断运行大约消耗3~5个电量
定位精度和手机当前GPS、WiFi、基站等信号强弱有关。
（1）好友手机没开流量；
（2）好友手机所在位置信号有遮挡比如地铁，乡村郊区等基站信号建设不发达地区；
好友在室内定位信号被遮挡，建议室内开启WiFi定位；
好友在室外有树林戓者周边建筑物突出有遮挡；