·直接运行postgres进程启动。
[pgsql@pg1 ~]$ postgres -D /postgresql/pgdata/ &
·使用pg_ctl命令启动数据库
[pgsql@pg1 ~]$ pg_ctl -D /postgresql/pgdata/ start
--使用pg_ctl 取消正在执行的sql
postgres=# select pg_backend_pid();
pg_backend_pid
----------------
6945
(1 row)
postgres=# select pg_sleep(600);
[pgsql@pg1 ~]$ pg_ctl kill INT 6945
postgres=# select pg_sleep(600);
ERROR: canceling statement due to user request
PS:上面的示例说明向进程发送的INT信号把正在执行的SQL命令取消了
--postgres单用户模式就是启动postgres程序时加上“--single”参数，这时postgres进程不会进入后台服务模式，而是进入交互式的命令行模式下
[pgsql@19c ~]$ postgres --single -D /postgresql/pgdata/ postgres
PostgreSQL stand-alone backend 13.2
backend> vacuum full;
backend>
[pgsql@19c ~]$
PS:用于清理过期事务
--该文件位于数据库实例的目录（$PGDATA）下。此文件中的每个参数配置项的格式都是“参数名=参数值”
所有的配置参数都在系统视图“pg_settings”中
1) “autovacuum_vacuum_cost_delay”的时间单位时
postgres=# select unit from pg_settings where name = 'autovacuum_vacuum_cost_delay';
unit
------
ms
postgres=# select short_desc,extra_desc from pg_settings where name = 'autovacuum_vacuum_cost_delay';
short_desc | extra_desc
----------------------------------------------------+------------
Vacuum cost delay in milliseconds, for autovacuum. |
2) 参数分类：
·postmaster：改变这类参数的值需要重启PostgreSQL实例。
·sighup：在postgresql.conf文件中改变这类参数的值不需要重启数据库，只需要向postmaster进程发送SIGHUP信号，让其重启装载配置新的
参数值就可以了。当然postmaster进程接收到SIGHUP信号后，也会向它的子进程发送SIGHUP信号，让新的参数值在所有的进程中生效。
·backend：在postgresql.conf文件中更改这类设置无须重新启动服务器，只需要向postmaster发送一个SIGHUP信号，让它重新读取
postgresql.conf文件中新的配置值，但新的配置值只会出现在修改之后的新连接中，已有的连接中该参数的值不会改变。这类参数的值也可以在
新建连接时由连接的一些参数改变。例如，通过libpq的PGOPTIONS环境变量可以改变本连接的配置值。
·superuser：这类参数可以由超级用户使用SET命令来改变，如检测死锁的超时时间的参数“deadlock_timeout”。而超级用户改变此参数值时
只会影响自身的sesssion配置，不会影响其他用户关于此参数的配置。向Postmaster进程发送SIGHUP信号也只会影响后续创建的连接，不会影
响已有的连接
·user：这类参数可以由普通用户使用SET命令来改变本连接中的配置值。除了普通用户也可以改变外，这类参数与superuser类参数没有区
别。可以通过查询pg_settings表中的context字段值来了解改变参数在postgresql.conf文件中的配置值时，是否需要重启数据库，示例如下。
要想知道改变参数“wal_buffers”的值是否需要重启数据库，可以用如下SQL语句查询：
postgres=# select name,context from pg_settings where name like 'wal_buffers';
name | context
-------------+------------
wal_buffers | postmaster
PS:的结果是“postmaster”，必须重启生效
postgres=# select name,context from pg_settings where name like 'local_preload_libraries';
name | context
-------------------------+---------
local_preload_libraries | user
PS：参数类型是“backend”，pg_ctl reload生效
·listen_addresses：string类型，声明服务器监听客户端连接的TCP/IP地址，改变此参数需要重启数据库服务。如果主机有多个IP地址，则让PostgreSQL服务在多个IP地址上监听，该参数的配置值就是由逗号分隔的多个IP地址值或IP地址值对应的主机名组成的一个列表。通常把此项配置为“*”，表示在本机的所有IP地址上监听。当然也可以配置成“0.0.0.0”，它与“*”相同，也表示在本机所有的IP地址上监听。如果这个列表是空的，那么服务器不会监听任何IP地址，在这种情况下，只有UNIX域套接字可以连接到数据库。此参数的默认值是“localhost”，表示只允许本地使用“loopback”连接到数据库，其他机器无法连接。更精细的控制项，如哪些IP或哪些网段可以连接服务器，是由配置文件“pg_hba.conf”来控制的。当然，listen_addresses也可以控制只在一个特定的IP地址上监听，所以可以有针对性地阻止不安全网卡的恶意连接请求。
·port：integer类型，指定服务器监听的TCP端口，默认为“5432”。改变该参数需要重启数据库服务。请注意，同一个端口号用于服务器监听的所有IP地址。
·max_connections：integer类型，允许与数据库连接的最大并发连接数。改变该参数需要重启数据库服务。默认值通常是“100”，但是如果内核设置不支持（在initdb时判断），该值可能会小于这个数。这个参数只能在服务器启动的时候设置。增大该参数可能会让PostgreSQL申请更多的System V共享内存或信号灯，可能会因超过操作系统默认配置值而导致实例无法启动。当运行HOT Standby服务器时，该参数必须大于或等于主服务器上的参数，否则HOT Standby服务器上可能无法执行查
询操作。
·superuser_reserved_connections：integer类型，决定为PostgreSQL超级用户连接而保留的连接数。改变该参数需要重启数据库服务。默认值是“3”。设置该参数的目的在于防止因普通用户消耗掉允许的所有连接而导致超级用户无法连接到数据库。普通用户最多建max_connections，superuser_reserved_connections个连接后就不再允许连接数据库了，这时超级用户还可以连接到数据库。该值必须小于max_connections的值。
·unix_socket_directory：string类型，声明服务器监听客户端连接的UNIX域套接字目录。该参数只能在编译时修改。默认值通常是“/tmp”。除了套接字文件本身，名为“.s.PGSQL.nnnn”“.s.PGSQL.nnnn.lock”（nnnn是服务器的端口号）的文件会在unix_socket_directory路径下创建，这两个文件都不应被手动删除。Windows下没有UNIX域套接字，因此该参数与Windows无关。
·unix_socket_group：string类型，设置UNIX域套接字的所属组（套接字的所属用户总是启动服务器的用户）。改变该参数需要重启数据库服务。可以与选项“unix_socket_permissions”一起用于对套接字进行访问控制。默认是一个空字符串，表示启动服务器的用户所属的默认组。该选项只能在服务器启动时设置。Windows下没有UNIX域套接字，因此该参数与Windows无关。
·unix_socket_permissions：integer类型，设置UNIX域套接字的访问权限。改变该参数需要重启数据库服务。UNIX域套接字文档的权限与普通的UNIX文件系统权限相同，该选项的值应该是数值形式，也就是chmod函数和umask函数中接受的形式。如果使用八进制格式，数字必须以0开头。默认的权限是“0777”，意思是任何用户都可以连接。通常合理的设置也可能是“0770”（只有用户和同组的用户可以访问)和“0700”（只有用户自己可以访问）。需要注意的是，对于UNIX域套接字，只有写权限有意义，读和执行权限没有任何意义。Windows下没有UNIX域套接字，因此该参数与Windows无关。
·bonjour：boolean类型，Bonjour也称为零配置联网，是苹果电脑公司的一个服务器搜索协议，此参数表示是否让Bonjour搜索到PostgreSQL服务。改变该参数需要重启数据库服务。默认值是“off”。
·bonjour_name：string类型，声明Bonjour服务名称。改变该参数需要重启数据库服务。默认值为空字符串，表示使用本机名。如果编译时没有打开Bonjour支持，那么将忽略该参数。
·tcp_keepalives_idle：integer类型，表示在一个TCP连接中空闲多长时间后会发送一个keepalive报文。默认值为“0”，表示使用操作系统设置的默认值，因为Windows不支持读取系统默认值，在Windows操作系统上此值若设置为“0”，系统会将该参数设置为2小时。该参数只有在支持TCP_KEEPIDLE或TCP_KEEPALIVE功能的操作系统上才可用，如Windows和Linux。在不支持此功能的操作系统上必须设置为“0”。此参数只对TCP连接有用，UNIX域套接连接会忽略该参数。
·tcp_keepalives_interval：integer类型，在一个空闲TCP连接中，定义在发送第一个TCP keepalive包后，如果在该参数给定的时间间隔内没有收到对端的回包，则开始发送第二个TCP keepalive包，若在给定的时间间隔内仍未收到回包的话则发送第三个keepalive包，直到达到tcp_keepalives_count次后都没有收到回包，则认为连接已中断，关闭连接。若指定为“0”，即表示使用操作系统设置的默认值，但在Windows操作系统上，因为Windows不支持读取系统默认值，此值若设置为“0”，系统会将该参数设置为1秒。该参数只有在支持TCP_KEEPIDLE或TCP_KEEPALIVE功能的操作系统上才可用，如Windows和Linux。在不支持此功能的操作系统上，必须设置为“0”。此参数只对TCP连接有用，UNIX域套接连接会忽略该参数。
·tcp_keepalives_count：integer类型，在一个空闲TCP连接上，发送keepalive包后，如果一直没有收到对端的回包，最多发送keepalive次报文后就认为TCP连接已中断。若指定为“0”，即表示使用操作系统设置的默认值。该参数只有在支持TCP_KEEPCNT功能的操作系统上才可用，在不支持此功能的操作系统上，必须设置为“0”。Windows操作系统也不支持此参数，所以也必须设置为“0”。此参数只对TCP连接有用，UNIX域套接连接会忽略该参数。在上面的参数中，需要注意的是TCP的keepalive参数的设置，在Linux环境下，通常要把tcp_keepalives_idle设置为较短的时间值。默认设置为“0”时，使用操作系统的设置值，通常为7200秒，即2小时，这个时间间隔对于大多数应用来说都太长了，所以需要设置为较短的时间值，如下面的配置：
tcp_keepalives_idle = 180
tcp_keepalives_interval = 10
tcp_keepalives_count = 3
在PostgreSQL中主要有以下几个内存配置参数。
·shared_buffers：integer类型，设置数据库服务器将使用的共享内存缓冲区数量，此缓冲区为数据块的缓存使用。此缓冲区是放在共享内存中的。每个缓冲区大小的典型值是8KB，除非在编译时修改了BLCKSZ的值。默认值通常是“4000”，对于8KB的数据块则共享内存缓冲区大小为4000×8KB≈32MB。这个数值必须大于16，并且至少是max_connections数值的两倍。通常会把此值设置得大一些，这样可以改进性能。在安装生产系统时，建议至少将该值设置为几千。如果有专用的1GB或更多内存的数据库服务器，一个合理的shared_buffers开始值可以是物理内存的25%。但把shared_buffers设置得太大，如超过物理内存的40%后，就会发现缓存的效果并不明显，这是因为PostgreSQL是运行在文件系统之上的，若文件系统也有缓存，将导致双缓存过多，产生负面影响。通常情况下，将share_buffers设置为物理内存的25%，而把更多的内存留给文件系统的缓存。在Windows环境下也是如此。在早期的PostgreSQL版本下，增大该参数的值可能会要求更多System V共享内
存，可能会超出操作系统共享内存配置参数允许的大小。
·temp_buffers：integer类型，设置每个数据库会话使用的临时缓冲区的最大数目。此本地缓冲区只用于访问临时表。临时缓冲区是在某个连接会话的服务进程中分配的，属于本地内存。临时缓冲区的大小也是按数据块大小来分配的，默认值是“1000”，对于8KB的数据块大小为8MB。每个会话可以使用SET命令改变此设置值，但是必须在会话第一次使用临时表前设置才有效，一旦使用了临时表，再改变该数值将是无效的。并不是一启动会话就分配这么多临时缓冲区的内存，而是按需分配，在需要时才分配实际的临时缓冲区内存。如果在一个并不需要大量临时缓冲区的会话里设置一个较大的数值，它的开销只是一个缓冲区描述符，每个BLOCK就会增加大约64B的内存用于存储缓冲区描述符。
·work_mem：integer类型，声明内部排序操作和Hash表在开始使用临时磁盘文件之前使用的内存数目。这个内存也是本地内存，以千字节为单位，默认是1024 KB（1MB）。请注意，对于复杂的查询，可能会同时并发运行多个排序或散列（Hash）操作；每个排序或散列操作都会分配该参数声明的内存来存储中间数据，只有存不下时才会使用临时文件。同样，多个正在运行的会话可能会同时进行排序操作，因此使用的总内存可能是work_mem的好几倍。ORDER BY、DISTINCT和MERGEJOINS都要用到排序操作。Hash表在Hash Join、以Hash为基础的聚集、以Hash为基础的IN子查询处理中也都要用到排序。
·maintenance_work_mem：integer类型，声明在维护性操作，比如VACUUM、CREATE INDEX和ALTER TABLE ADD FOREIGN KEY中使用的最大内存数以KB为单位，默认是16MB。在一个数据库会话里，只有这样的操作可以执行，并且一个数据库实例通常不会有太多这样的工作并发执行，通常把该数值设置得work_mem大一些较为合适。更大的设置可以提高上述操作的执行效率。
--配置AutoVacuum后，达到autovacuum_max_workers的时间，内存会被分配，因此也不要将默认值设置得太大，而当需要手动执行上述操作时，可以使用SET命令把此参数值设置得大一些。
·max_stack_depth：integer类型，声明服务器的执行堆栈的最大安全深度。此设置默认为2MB，如果发现不能运行复杂的函数时，可以适当提高此配置的值，不过通常情况下保持默认值就足够了。把max_stack_depth参数设置得大于实际的操作系统内核限制值时，意味着一个正在运行的递归函数可能会导致PostgreSQL后台服务进程崩溃。在一些操作系统平台上，PostgreSQL能够检测出内核限制，这时PostgreSQL将不允许其设置为一个不安全的值。但PostgreSQL并不能在
所有的操作系统平台上都能检测出操作系统的内核限制值，所以建议还是设置一个明确的值
1）wal_level：enum类型，可以选择的值为“minimal”“replica”“logical”，此配置项决定了多少信息写入WAL日志中。改变该参数需要重启数据库服务。默认值是“minimal”，即只写入在数据库崩溃或突然关机后进行恢复时所需要的信息。设置为“replica”，则会添加一些备库只读查询时需要的信息。当执行“CREATE TABLE AS”“CREATE INDEX”“CLUSTER”和“COPY intotables”等批量操作时，如果wal_level设置为“minimal”，那么批量操作只会产生很少的WAL日志，原因是这些批量操作的具体过程可以安全地跳过，并不会影响数据库的恢复，但“minimal”级别的WAL不包括所有从基础备份和WAL日志中重建数据的信息。如果要搭建物理备库，需要把此参数设置为“replica”；如果需要使用逻辑同步，需要把此参数设置为“logical”。
2）fsync：boolean类型，即是否使用fsync()系统调用（或等价调用）把文件系统中的脏页刷新到物理磁盘，确保数据库能在操作系统或者硬件崩溃的情况下恢复到一致的状态。改变该参数需要重新装载配置文件。此参数默认值为“on”，大多数情况下都应该把这个参数设置为“on”。但当此数据库不是很重要，或者此数据库中的数据很容易在其他系统中重建时，为了提高性能，可以把此参数设置为“off”。例如，从备份文件中初始加载一个新数据库时，可以把此参数设置为“off”，这样可以提升重建的速度。如果这个选项被关闭，那么可以考虑关闭full_page_writes，因为把fsync设置为“off”后，把full_page_writes设置为“on”也无法保证数据的安全性，不如索性全部设置为“off”。
3）synchronous_commit：boolean类型，声明提交一个事务是否需要等待其把WAL日志写入磁盘后才返回，默认值是“on”。为了事务的安全，通常都应当设置为“on”。不同于fsync，将此参数设置为“off”不会产生数据库不一致性的风险，只会导致用户已提交成功的最近的几个事务丢失，即在数据库崩溃或突然关机后，重启数据库时用户会发现故障时间点附近的几个事务实际上并没有提交成功，而是回滚了，而数据库状态是一致的。一般用户可以直接改变此参数值，因此在提交一些不重要的事务时，可以先把此参数设置为“off”，然后再提交，这样就可以提高数据库性能。
4）wal_sync_method：enum类型，用来指定向磁盘强制更新WAL日志数据的方法。一般保持默认值就可以了。如果fsync设置为“off”，那么该参数的设置就没有意义。该参数的可选项有以下几种。
·open_datasync：使用O_DSYNC选项的open()函数打开WAL日志，Linux操作系统不支持此选项。Windows下默认使用此选项。
·fdatasync：每次提交时调用fdatasync函数。Linux操作系统上默认使用此选项。fsync_writethrough：每次提交时调用fsync()函数，同时把所有Cache都刷新到物理硬盘中。Linux操作系统不支持此选项。Windows下支持此选项。
·fsync：每次提交时调用fsync()函数。大多数平台都支持此选项。·open_sync：使用O_SYNC选项的open()函数来打开WAL日志。大多数平台都支持此选项。
5）full_page_writes：boolean类型。打开该选项时，PostgreSQL服务器会在检查点（checkpoints）之后对页面进行第一次修改时将整个页面写到WAL日志中。这样做是因为在操作系统崩溃过程中可能只有部分页面写入磁盘了，从而导致在同一个页面中会有新旧数据混合的情况。在崩溃后的恢复期，如果WAL日志中没有记录完整的页，且页中的数据是新旧混合的，则无法完全恢复该页。把完整的页面保存在WAL日志中就可以直接使用WAL日志中的页覆盖坏页（包含新旧混合的数据）以完成恢复工作。此参数的默认值为“on”，为了数据安全，通常使用该默认设置。运行到检查点时，若页面第一次被修改，则整个页面会被写入WAL日志中，但在下一个检查点到来之后该页面若再发生变化，将不会再记录整个页面。也就是说，在两个检查点之间，不管这个页面变化了多少次，只在第一次变化时记录整个页面到WAL日志中，后面的就不会再记录了。所以，增加检查点产生的时间间隔就能减少WAL的日志量。
6）wal_buffers：integer类型，指定放在共享内存中用于存储WAL日志的缓冲区的数目。默认值为“8”，即64KB。改变此参数需要重启数据库服务。此参数设置值的大小只需要能够保存一次事务生成的WAL数据即可，这些数据在每次事务提交时都会写入磁盘。通常此参数设置为8~128（64KB~1MB）。
7）wal_writer_delay：integer类型，指定wal writer process把WAL日志写入磁盘的周期。在每个周期中会把缓存中的WAL日志刷新到磁盘上，休眠wal_writer_delay时间，然后重复上述过程。默认时间为200毫秒。当把synchronous_commit参数设置为“on”时，实际上在每次事务提交时都会把缓存中的WAL日志刷新到磁盘上，因此该参数通常在synchronous_commit参数设置为“off”时比较有用。当synchronous_commit参数设置为“off”时，wal_writer_delay参数的值决定了数据库实例、操作系统或硬件崩溃时，最多丢失多长时间内已提交事务的数据。
8）commit_delay：integer类型，指定向WAL缓冲区写入记录和将缓冲区刷新到磁盘上之间的时间延迟，以微秒为单位。非零的设置值允许多个事务共用一个fsync()系统调用刷新数据。如果系统负载足够高，那么在给出的时间间隔里，其他事务可能已经准备好提交了。但是如果没有其他事务准备提交，那么该延迟就是在浪费时间。因此，该延迟只在一个服务器进程写其提交日志时，且至少commit_siblings个其他事务处于活跃状态的情况下执行。默认是“0”（无延迟）。
9）commit_siblin gs：integer类型，在执行commit_delay延迟时要求同时打开的最小并发事务数。默认是“5”
logging_collector = on
相当于：
log_rotation_age = 1d
log_rotation_size = 10MB
每次重启数据库时也会生成一个新的日志文件。
PS:在这种方式下，PostgreSQL并不会自动清理日志文件，需要写一个脚本程序来清理日志文件
2）PostgreSQL数据库也可以把日志发送到操作系统的syslog中，或者多生成一个csv格式的日志，此操作通过配置log_destination参数来完成。
log_destination = 'syslog'
or
logging_collector = on
log_destination = 'csvlog'
PS:要生成csvlog，需要打开“logging_collector”，如果在syslog和eventlog中生成日志，则不需要打开“logging_collector”。
3）常用的日志方法是将PostgreSQL数据库配置成保留固定数目的日志，如保留一周的日志，到了星期一，则把上星期一的日志覆盖
掉，配置方法如下：
log_filename = 'postgresql-%u.log'
log_rotation_age = 1d
log_truncate_on_rotation = on
PS:其中“%u”代表星期几，星期一到星期日对应的值是1~7，将log_truncate_on_rotation设置为“on”，就会覆盖上周的日志文件，以此来保证只保留7天的日志文件
postgresql-1.log
postgresql-2.log
postgresql-3.log
postgresql-4.log
postgresql-5.log
postgresql-6.log
postgresql-7.log
4）·log_destination：可以设置为“stderr”“csvlog”和“syslog”。
·logging_collector：可以设置为“on”或“off”。
·log_directory：日志输出的路径，可以是绝对路径或数据目录的相对路径。
·log_filename：文件名，可以带上格式字符串。
·log_rotation_age：日志超过多长时间后就生成一个新的文件。
·log_rotation_size：日志超过多大时就生成一个新的文件。
·log_truncate_on_rotation：当生成的新文件的文件名已经存在时，是否覆盖同名旧文件。只有基于时间的文件切换才会覆盖，服务器重启时的文件切
换并不会覆盖。
·syslog_facility：该参数是设置了log_destination='syslog'后，指定syslog的“facility”项。可以设置为LOCAL0、LOCAL1、LOCAL2、LOCAL3、LOCAL4、LOCAL5、LOCAL6、LOCAL7中的一个值。
·syslog_ident：当使用syslog时，用于在syslog日志中标识PostgreSQL的程序名。默认为“postgresql.conf”。PostgreSQL数据库也可以设置log的级别，log的级别控制着记录日志的多少，而log的级别由参数“log_min_messages”来控制，可以取值为：DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、INFO、NOTICE、WARNING、ERROR、LOG、FATAL、PANIC，级别排序越靠后，则打印到日志文件中的内容就越少。PostgreSQL也有类似MySQL中的慢查日志功能，也就是把一些运行慢的SQL语句记录到日志中，在PostgreSQL中该功能是由参数“log_min_duration_statement”来控制的，如果某个SQL语句的运行时间大于或等于设定的毫秒数，那么该SQL语句和它运行的时间就会被记录到日志中。当设置为“0”时，则所有运行的SQL语句及其时间都会被记录到日志文件中。另外，PostgreSQL也可以记录一个SQL语句产生了一定级别的日志（通常是错误日志，也可以把该SQL语句记录到日志中），这一功能是由参数“log_min_error_statement”来控制的，该参数的取值与log_min_messages的取值一样，可以取DEBUG5、DEBUG4、DEBUG3、DEBUG2、DEBUG1、INFO、NOTICE、WARNING、ERROR、LOG、FATAL、PANIC中的一个值，如果设置为“NOTICE”，这条SQL语句运行时产生了NOTICE日志，则该SQL语句也会被记录到日志中。设置为“PANIC”，则表示关闭该功能，因为SQL语句不可能生成“PANIC”日志。PostgreSQL日志还可以控制是否记录DDL、DML或所有SQL语句，该功能是由参数“log_statement”来控制的。当设置为“none”时，不记录SQL语句。当设置为“ddl”时，记录所有DDL语句。当设置为“mod”时，记录INSERT、UPDATE、DELETE、TRUNCATE、COPY FROM等，如果PREPARE、EXECUTE或EXPLAIN ANALYZE语句产生了更新，这些语句也同样会被记录下来。当设置为“all”时，则所有SQL语句都会被记录，如果使用了参数
“log_min_duration_statement”，超过一定时间的SQL语句已在日志中被打印，而这些SQL语句又符合log_statement参数配置并要求输出到日志中，则SQL语句不会在日志中重复打印两次，只会打印一次。
5）PostgreSQL中还有以下调试SQL执行计划及过程的日志参数。
·debug_print_parse：设置为“on”时，把SQL的解析树打印到日志中。
·debug_print_rewritten：设置为“on”时，把SQL的查询重写打印到日志中。
·debug_print_plan：设置为“on”时，把SQL的执行计划打印到日志中。
·debug_pretty_print：是否缩进上面3种日志以使其更易读。PostgreSQL还有很多日志开关，可以由用户决定把哪些信息记录到日志中。
·log_checkpoints：是否记录checkpoint。
·log_connections：是否记录客户端的连接。
·log_disconnections：是否记录客户端断开连接的信息。
·log_duration：是否记录每个已完成语句的持续时间，对于使用扩展查询协议的客户端，语法分析、绑定、执行，每一步所用的时间都分别进行记录。
·log_hostname：是否记录客户端的主机名。
·log_lock_waits：当一个会话等待时间超过deadlock_timeout时，是否记录一条日志信息。当SQL有排序、临时查询结果或Hash时会生成临时文件，这些临时
文件有时会比较大，需要进行监控，可以设置参数“log_temp_files”为一个整数值，当生成的临时文件大于这个值时，则把临时文件的信息打印到日志文件中。
1）pg_hba.conf文件由很多记录组成，每条记录占一行。以#开头的注释及空白行会被忽略
local [auth-options]
host [auth-options]
hostssl [auth-options]
hostnossl [auth-options]
host [auth-options]
hostssl [auth-options]
hostnossl [auth-options]
·local：这条记录匹配通过UNIX域套接字的连接认证。没有这种类型的记录就不允许UNIX域套接字的连接。当psql后面不指定主机名或IP地址时，即用UNIX域套接字的方式连接数据库。
·host：这条记录匹配通过TCP/IP进行的连接，包括SSL和非SS的连接。
·hostssl：这条记录匹配使用TCP/IP的SSL连接，且必须是使用SSL加密的连接。要使用该选项，编译服务器时必须打开SSL支持，而且启动服务器时必须打开SSL配置选项。
·hostnossl：这条记录与hostssl相反，只匹配那些在TCP/IP上不使用SSL的连接请求。记录中第二个字段设置一个数据库名称，如果设置为“all”，表示可以匹配任何数据库。如果设置为“replication”，表示允许流复制连接，而不是允许连接到一个名为“replication”的数据库上。记录中第三个字段设置一个用户的名称，如果设置为“all”，表示可以匹配任何用户。
表示允许哪些IP地址来访问此服务器，如192.168.1.10/32表示只允许192.168.1.10这台主机访问该数据库（因为掩码为32，完全匹配此IP），192.168.1.0/24表示IP地址前缀为192.168.1.X的主机都允许访问数据库服务器。表示验证方法，PostgreSQL支持的认证方式很多，但
常用的只有trust、reject、md5和ident方法。平时只需要掌握这几种方式的配置方法就可以了，其他认证方法在使用时查询相关的资料即可。
记录中最后一项[auth-options]表示认证选项
--PostgreSQL中支持以下几种验证方法。
·trust：无条件地允许连接。此方法允许任何可以与PostgreSQL数据库服务器连接的用户以任意PostgreSQL数据库用户身份进行连接，不需
要口令或任何其他认证。
·reject：无条件地拒绝连接。reject行可以阻止一个特定的主机连接，而允许其他主机连接数据库。这相当于设置了一个黑名单。
·md5：要求客户端提供一个MD5加密的口令进行认证。
·password：要求客户端提供一个未加密的口令进行认证。因为口令是以明文形式在网络上传递的，所以不应该在不安全的网络上使用此方式。一般这种方法使用得很少。
·gss：用GSSAPI认证用户。只有在进行TCP/IP连接时才能用。
·sspi：用SSPI来认证用户。仅在Windows系统上使用。
·krb5：用Kerberos V5认证用户。只有在进行TCP/IP连接时才能用。
·ident：通过联系客户端的ident服务器获取客户端操作系统的用户名，并且检查它是否匹配被请求的数据库用户名。ident认证只能在TCP/IP连接上使用。当为本地连接指定这种认证方式时，将用peer认证来替代。服务器为了确定接收到的连接请求确实是客户端机器上的osdba用户发起的，而不是这台机器上其他用户发起的假冒请求，会向客户端机器上的ident服务发起请求，让ident服务查看此TCP连接是否是osdba用户发起的，如果不是，则认证失败。如果客户端通过本地连接连接到服务器，因为客户端与服务器在一台机器上，数据库服务器可以直接检查客户端用户的操作系统用户身份，就不需要向ident服务发送请求进行判断了。
·peer：数据库端允许客户端上的特定操作系统用户连接到数据库。这种认证方式的使用场景如下。客户端是主机上某个操作系统用户，已经通过了操作系统的身份认证，是数据库服务器可以信任的用户，不需要在数据库层面再次检测其身份。例如，如果配置了这种认证方式（配置中允许的用户名为“osdba”），这时在操作系统用户“osdba”下，就能以数据库用户osdba的身份连接到数据库。这种认证方式与Oracle数据库的操作系统用户认证类似，在Oracle数据库中，进入操作系统oracle用户后，不需要密码就能以“sysdba”的身份连接到本机的Oracle数据库上。
·ldap：用LDAP服务器认证。
·radius：用RADIUS服务器认证。
·cert：用SSL客户端证书认证。
·pam：用操作系统提供的可插入认证模块服务（PAM）来认证。trust认证方法一般与UNIX域套接字的连接认证组合使用，对于单用户工作站的本地连接是非常合适和方便的，因为这台机器只有用户使用，不存在安全性问题。如果在多用户的机器上使用trust认证方式，默认情况下，这台机器上的任何操作系统用户都可以使用数据库超级用户连接到数据库，这会导致安全问题。为了防止一般的操作系统用户连接到数据库，需要设置PostgreSQL的UNIX域套接字文件（默认
为/tmp/.s.PGSQL.5432）的访问权限。要做这些限制，可以设置unix_socket_permissions参数和unix_socket_group参数，也可以设置unix_socket_directory，把UNIX域套接字文件放在一个其他用户无法访问的目录中。对于TCP/IP的连接认证，也可以使用trust认证方法，但TCP/IP方式会导致远程机器上的任何操作用户都可以连接到数据库，从而带来安全问题。以密码为基础的认证方法包括md5和password。这两种方法在操作上非常类似，但在password方式中，密码是明文在网络上传输的，在不安全的网络上密码可能会被截取，所以通常都用md5方式。ident认证方法也是用得较多的认证方式，这种方式通常与UNIX域套接字的连接认证方式组合使用，这样就可以以操作系统用户认证的方式连接到数据库中。例如，在操作系统下创建了一个用户“postgres”，数据库中也有一个用户“postgres”，设定ident认证方式后，在操作系统用户“postgres”下，可以直接连接到数据库中，而不需要密码。
1）一台机器只给数据库使用，而没有其他用途，则可以在pg_hba.conf中进行如下配置
local all all trust
2）在数据库主机上使用密码验证，可以使用如下配置：
local all all md5
3）让其他主机的连接都使用md5密码验证
host all all 0.0.0.0/0 md5
4）如果数据库中有一个用户“osdba”，操作系统中也有一个用户“osdba”，在操作系统“osdba”用户下连接数据库不需要密码验证的设
置方法如下
local all osdba ident