在http://blog.163.com/donfang_jianping/blog/static/13647395120155299412856/中，我们介绍了PostgreSQL在Linux上的安装，这里我们来看一下PostgreSQL有那些初始化参数。

这个是摘抄的别人的，写个人说明，这个就是让你来看看都有哪些类型的参数，等你以后想修改或者使用的时候就可以心中有数，查看这些参数及设置应该是用show \set \pset select 参数 比如show all ；至于哪些用\pset 哪些用\set 哪些用show查看 哪些用select查看，有知道的可以@我，发给我，
x先看看英文的
19.1. Setting Parameters
19.1.1. Parameter Names and Values
All parameter names are case-insensitive. Every parameter takes a value of one of five types: boolean, string, integer, floating point, or enumerated (enum). The type determines the syntax for setting the parameter:

Boolean: Values can be written as on, off, true, false, yes, no, 1, 0 (all case-insensitive) or any unambiguous prefix of one of these.

String: In general, enclose the value in single quotes, doubling any single quotes within the value. Quotes can usually be omitted if the value is a simple number or identifier, however.

Numeric (integer and floating point): A decimal point is permitted only for floating-point parameters. Do not use thousands separators. Quotes are not required.

Numeric with Unit: Some numeric parameters have an implicit unit, because they describe quantities of memory or time. The unit might be kilobytes, blocks (typically eight kilobytes), milliseconds, seconds, or minutes. An unadorned numeric value for one of these settings will use the setting's default unit, which can be learned from pg_settings.unit. For convenience, settings can be given with a unit specified explicitly, for example '120 ms' for a time value, and they will be converted to whatever the parameter's actual unit is. Note that the value must be written as a string (with quotes) to use this feature. The unit name is case-sensitive, and there can be whitespace between the numeric value and the unit.

Valid memory units are kB (kilobytes), MB (megabytes), GB (gigabytes), and TB (terabytes). The multiplier for memory units is 1024, not 1000.

Valid time units are ms (milliseconds), s (seconds), min (minutes), h (hours), and d (days).

Enumerated: Enumerated-type parameters are written in the same way as string parameters, but are restricted to have one of a limited set of values. The values allowable for such a parameter can be found from pg_settings.enumvals. Enum parameter values are case-insensitive.

19.1.2. Parameter Interaction via the Configuration File
The most fundamental way to set these parameters is to edit the file postgresql.conf, which is normally kept in the data directory. A default copy is installed when the database cluster directory is initialized. An example of what this file might look like is:

This is a comment

log_connections = yes
log_destination = 'syslog'
search_path = '"$user", public'
shared_buffers = 128MB
One parameter is specified per line. The equal sign between name and value is optional. Whitespace is insignificant (except within a quoted parameter value) and blank lines are ignored. Hash marks (#) designate the remainder of the line as a comment. Parameter values that are not simple identifiers or numbers must be single-quoted. To embed a single quote in a parameter value, write either two quotes (preferred) or backslash-quote.

Parameters set in this way provide default values for the cluster. The settings seen by active sessions will be these values unless they are overridden. The following sections describe ways in which the administrator or user can override these defaults.

The configuration file is reread whenever the main server process receives a SIGHUP signal; this signal is most easily sent by running pg_ctl reload from the command line or by calling the SQL function pg_reload_conf(). The main server process also propagates this signal to all currently running server processes, so that existing sessions also adopt the new values (this will happen after they complete any currently-executing client command). Alternatively, you can send the signal to a single server process directly. Some parameters can only be set at server start; any changes to their entries in the configuration file will be ignored until the server is restarted. Invalid parameter settings in the configuration file are likewise ignored (but logged) during SIGHUP processing.

In addition to postgresql.conf, a PostgreSQL data directory contains a file postgresql.auto.conf, which has the same format as postgresql.conf but should never be edited manually. This file holds settings provided through the ALTER SYSTEM command. This file is automatically read whenever postgresql.conf is, and its settings take effect in the same way. Settings in postgresql.auto.conf override those in postgresql.conf.

The system view pg_file_settings can be helpful for pre-testing changes to the configuration file, or for diagnosing problems if a SIGHUP signal did not have the desired effects.

19.1.3. Parameter Interaction via SQL
PostgreSQL provides three SQL commands to establish configuration defaults. The already-mentioned ALTER SYSTEM command provides a SQL-accessible means of changing global defaults; it is functionally equivalent to editing postgresql.conf. In addition, there are two commands that allow setting of defaults on a per-database or per-role basis:

The ALTER DATABASE command allows global settings to be overridden on a per-database basis.

The ALTER ROLE command allows both global and per-database settings to be overridden with user-specific values.

Values set with ALTER DATABASE and ALTER ROLE are applied only when starting a fresh database session. They override values obtained from the configuration files or server command line, and constitute defaults for the rest of the session. Note that some settings cannot be changed after server start, and so cannot be set with these commands (or the ones listed below).

Once a client is connected to the database, PostgreSQL provides two additional SQL commands (and equivalent functions) to interact with session-local configuration settings:

The SHOW command allows inspection of the current value of all parameters. The corresponding function is current_setting(setting_name text).

The SET command allows modification of the current value of those parameters that can be set locally to a session; it has no effect on other sessions. The corresponding function is set_config(setting_name, new_value, is_local).

In addition, the system view pg_settings can be used to view and change session-local values:

Querying this view is similar to using SHOW ALL but provides more detail. It is also more flexible, since it's possible to specify filter conditions or join against other relations.

Using UPDATE on this view, specifically updating the setting column, is the equivalent of issuing SET commands. For example, the equivalent of

SET configuration_parameter TO DEFAULT;
is:

UPDATE pg_settings SET setting = reset_val WHERE name = 'configuration_parameter';

另外就是配置文件postgresql.conf 这个里边可以加载多个参数文件用include_dir '配置文件的目录名' 然后将配置文件放到此目录下，或者include '配置文件'

在PostgreSQL当中，我们也可以通过查询数据库字典pg_settings来查看当前参数的一些配置。该数据字典类似于Oracle里面的v$parameter或是x$ksppi，x$ksppcv。
下面，我们来看一下pg_settings这个数据字典。
[pgsqladmin@pgsql ~]$ psql -d postgres
psql (9.4.4)
Type "help" for help.

postgres=# \d pg_settings
View "pg_catalog.pg_settings"
Column | Type | Modifiers 
------------+---------+-----------
name | text | 
setting | text | 
unit | text | 
category | text | 
short_desc | text | 
extra_desc | text | 
context | text | 
vartype | text | 
source | text | 
min_val | text | 
max_val | text | 
enumvals | text[] | 
boot_val | text | 
reset_val | text | 
sourcefile | text | 
sourceline | integer |

postgres=# 
它有这么多列。

PostgreSQL把参数分为如下几类，我们可以通过查询pg_settings来查看，如下，
postgres=# select distinct context from pg_settings;
context

backend
user
internal
postmaster
superuser
sighup
(6 rows)

postgres=# 
下面，我们来看一下这些类型的具体表示意义，
user：该类参数表示，普通用户可以通过set命令来更改参数的配置值。
internal：该类参数是内部参数，也就是说，不可以进行修改。不同于Oracle里面的隐含参数，隐含参数我们是可以修改的。
postmaster：该类参数更改配置项后，需要重启PostgreSQL实例才能生效。类似于Oracle里面的静态参数。
superuser：该类参数可以由超级用户来改变，改变时，只会影响到自身的session，不会影响到其他的用户。类似于Oracle里面的alter session set parameter = value或是alter session set parameter = value与alter system set parameter = value scope=spfile的结合。
sighup：在postgresql.conf配置文件中更改这种类型的参数无须重启实例，只需要向postmaster进程发送一个SIGHUP信号，让其重新读取配置文件即可。postmaster进程收到信号后，也会向其他子进程发送SIGHUP信号，让新的参数值在其他子进程中也生效。该类参数区别于backend类参数。

对于PostgreSQL参数，我把归为如下几类：
（1）与连接相关的参数。
listen_addresses：用来指定服务器监听TCP/IP地址，改变该参数时，需要重启数据库服务。如果存在多个IP，我们在配置的时候，使用逗号进行分隔。默认为localhost，表示只允许本地进行连接。我们也可以配置为“*”或是“0.0.0.0”，表示监听本机上的所有IP。具体更精通的网络控制的配置，是由配置文件pg_hba.conf配置文件来完成的（该配置文件类似于Oracle里的sqlnet.ora），在后续，我会再介绍该配置文件。
port：用来指定监听的端口，默认为5432，改变后，需要重启数据库服务。
max_connections：指定数据库允许的最大并发连接数，改变该参数需要重启数据库服务。该参数类似于Oracle里面的processes，sessions。
superuser_reserved_connections：指定PostgreSQL超级用户预保留的连接数，默认为3，改变后需要重启数据库服务。配置该参数的目的是防止普通用户把连接数占用完而超级用户连接不上。
unix_socket_directory：指定服务器监听客户端连接的unix套接字目录，该参数只能在编译的时候修改，默认为/tmp。
unix_socket_group：设置unix域套接字所属的组（套接字所属用户总是启动服务器的用户），改变该参数需要重启数据库服务。
unix_scoket_permissions：设置unix域套接字的访问权限，默认为0777，改变该参数需要重启数据库服务。
tcp_keepalives_idle：表示在一个TCP连接当中空闲多长时间后会发送一个keepalive报文，默认为0，表示使用操作系统设置的默认值。
tcp_keepalives_count：表示在一个空间的TCP连接上，发送keepalive报文后，如果一直没有收到回应，最多发送多少次后，就认为该连接已经中断了。
tcp_keepalives_interval：表示如果在发送一个keepalive包后，如果没有收到回应，再间隔多长时间发送一个。

与内存相关的配置项：
shared_buffers；该参数用来指定数据库服务器使用的共享内存的数量。一般情况下，设置为物理内存的25%。
该参数的值必须大于16，并且至少是max_connections数值的两倍。
temp_buffers：设置每个数据库会话使用临时缓冲区的最大数目，此内存结果只用于缓冲临时表的数据。
work_mem：用来指定一些排序或是散列操作所使用内存数目，如果所进行的操作超过了当前设置的大小，那么它会使用临时磁盘文件。
maintenance_work_mem：指定在进行维护性操作（比如create index，vacuum等）时所使用的最大内存量。
max_stack_depth：用来指定服务器执行堆栈的最大安全深度，默认为2M，如果发现不能运行复杂的函数，可以适当地提高此参数的值。

关于WAL日志一些参数：
wal_level：指定生成wal日志的级别，值为minmal，archive，hot_standby。minmal一般的配置，archive会生成wal归档需要的日志记录，hot_standby添加备库时需要设置。 
fsync：表示是否使用fsync()系统调用把文件系统中的脏页刷新到物理磁盘，确保数据库在崩溃的情况下可以恢复到崩溃前的状态，该值默认为true。
synchronous_commit：表示提交一个事务后，是否需要等待把wal日志写到磁盘后再返回，默认为true。
wal_sync_method：用来指定向磁盘强制更新wal日志的方法，一般采用默认值就OK。
full_page_writes：值为true或false，如果打开该选项时，PostgreSQL服务器会在检查点之后对页面第一次修改时将整个页面写到wal日志。
wal_buffers：用来指定在共享内存里用于存储wal日志的缓冲区数目，默认为8，即可64K，通常此参数设置为8——128（即64K到1M）就可以了。
wal_writer_delay：指定wal writer process把wal日志写入到磁盘的周期，默认为200毫秒。
commit_delay：用来指定向wal缓冲区写入记录和将缓冲区刷新到磁盘之间的时间延迟，默认0，表示没有延迟，单位为微秒。
commit_siblings：在执行commit_delay延迟时，要求同时打开的最少并发事务数，默认为5。

关于错误日志的一些参数：
logging_collector = on，表示打开日志搜集。
log_rotation_age：表示日志超过多长时间就生成一个新的日志文件。
log_rotation_size：表示日志超过多大的时候就会生成一个新的日志文件。
log_filename：指定日志文件名，比如logfilename = 'postgresql-%Y-%m-%d%u.log'。
log_directory：用来指定日志文件生成的目录。
另外，还有如下一些日志参数也可能会用到：
debug_print_parse：设置为on时，把SQL的解析树输出到日志中。
debug_print_rewritten：设置为on时，把SQL的查询重写打印到日志中。
debug_print_plan：设置为on时，把SQL的执行计划打印输出到日志中。
debug_pretty_print：美化上述的三种输出，使其更容易阅读。
log_checkpoint：是否记录checkpoint。
log_connections：是否记录客户端的连接。
log_disconnections：是否记录客户端断开的连接。
log_duration：是否记录每个已完成语句的持续时间。
log_hostname：是否记录客户端的主机名。
log_lock_waits：当一个会话的等待时间超过deadlock_timeout时，是否记录一条日志到日志文件中。

本文转自 aklaus 51CTO博客，原文链接:http://blog.51cto.com/aklaus/2059706