After the environment is set up, look at the directories it involves from the environment variables.
export PGHOME=/usr/local/pgsql/
export PGUSER=postgres
export PGPORT=5432
export PGDATA=/app/pgsql/data
export PGLOG=/app/pgsql/log/postgres.log
export PATH=$PGHOME/bin:$PATH:$HOME/bin
export LD_LIBRARY_PATH=$PGHOME/lib:$LD_LIBRARY_PATH
PATH=/usr/local/pgsql/bin:$PATH
export PATH
Directory structure and function
Software installation directory
/usr/local/pgsql/ Equivalent to Oracle's /app/oracle software installation directory, some commands that can be executed by psql, pg_ctl and other software are below.
[postgres@yuan ~]$ cd /usr/local/pgsql/
[postgres@yuan pgsql]$ ll
total 16
drwxr-xr-x 2 root root 4096 Jul 9 17:54 bin
drwxr-xr-x 6 root root 4096 Jul 9 17:54 include
drwxr-xr-x 4 root root 4096 Jul 9 17:54 lib
lrwxrwxrwx 1 root root 26 Jul 9 17:56 postgresql-12.4 -> /usr/local/postgresql-12.4
drwxr-xr-x 6 root root 4096 Jul 9 17:54 share
[postgres@yuan pgsql]$ cd bin
[postgres@yuan bin]$ ll
total 12348
-rwxr-xr-x 1 root root 73808 Jul 9 17:54 clusterdb
-rwxr-xr-x 1 root root 73552 Jul 9 17:54 createdb
-rwxr-xr-x 1 root root 78416 Jul 9 17:54 createuser
-rwxr-xr-x 1 root root 68944 Jul 9 17:54 dropdb
-rwxr-xr-x 1 root root 68920 Jul 9 17:54 dropuser
-rwxr-xr-x 1 root root 975928 Jul 9 17:54 ecpg
-rwxr-xr-x 1 root root 142520 Jul 9 17:54 initdb
-rwxr-xr-x 1 root root 44344 Jul 9 17:54 pg_archivecleanup
-rwxr-xr-x 1 root root 130528 Jul 9 17:54 pg_basebackup
-rwxr-xr-x 1 root root 172512 Jul 9 17:54 pgbench
-rwxr-xr-x 1 root root 66984 Jul 9 17:54 pg_checksums
-rwxr-xr-x 1 root root 42880 Jul 9 17:54 pg_config
-rwxr-xr-x 1 root root 61376 Jul 9 17:54 pg_controldata
-rwxr-xr-x 1 root root 76888 Jul 9 17:54 pg_ctl
-rwxr-xr-x 1 root root 422888 Jul 9 17:54 pg_dump
-rwxr-xr-x 1 root root 109376 Jul 9 17:54 pg_dumpall
-rwxr-xr-x 1 root root 73064 Jul 9 17:54 pg_isready
-rwxr-xr-x 1 root root 93208 Jul 9 17:54 pg_receivewal
-rwxr-xr-x 1 root root 93832 Jul 9 17:54 pg_recvlogical
-rwxr-xr-x 1 root root 71256 Jul 9 17:54 pg_resetwal
-rwxr-xr-x 1 root root 187840 Jul 9 17:54 pg_restore
-rwxr-xr-x 1 root root 109784 Jul 9 17:54 pg_rewind
-rwxr-xr-x 1 root root 49216 Jul 9 17:54 pg_test_fsync
-rwxr-xr-x 1 root root 39152 Jul 9 17:54 pg_test_timing
-rwxr-xr-x 1 root root 148952 Jul 9 17:54 pg_upgrade
-rwxr-xr-x 1 root root 103904 Jul 9 17:54 pg_waldump
-rwxr-xr-x 1 root root 8227064 Jul 9 17:53 postgres
lrwxrwxrwx 1 root root 8 Jul 9 17:53 postmaster -> postgres
-rwxr-xr-x 1 root root 615376 Jul 9 17:54 psql
-rwxr-xr-x 1 root root 78032 Jul 9 17:54 reindexdb
-rwxr-xr-x 1 root root 86968 Jul 9 17:54 vacuumdb
data directory
/app/pgsql/data It is equivalent to the data directory specified by Oracle when building the database. The parameter files and data files required by the database are all below.
[postgres@yuan include]$ cd /app/pgsql/data
[postgres@yuan data]$ ll
total 60
drwx------ 5 postgres postgres 41 Jul 9 18:02 base
drwx------ 2 postgres postgres 4096 Jul 9 18:06 global
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_commit_ts
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_dynshmem
-rw------- 1 postgres postgres 4789 Jul 9 18:03 pg_hba.conf
-rw------- 1 postgres postgres 1636 Jul 9 18:02 pg_ident.conf
drwx------ 4 postgres postgres 68 Jul 9 18:10 pg_logical
drwx------ 4 postgres postgres 36 Jul 9 18:02 pg_multixact
drwx------ 2 postgres postgres 18 Jul 9 18:05 pg_notify
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_replslot
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_serial
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_snapshots
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_stat
drwx------ 2 postgres postgres 63 Jul 9 20:50 pg_stat_tmp
drwx------ 2 postgres postgres 18 Jul 9 18:02 pg_subtrans
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_tblspc
drwx------ 2 postgres postgres 6 Jul 9 18:02 pg_twophase
-rw------- 1 postgres postgres 3 Jul 9 18:02 PG_VERSION
drwx------ 3 postgres postgres 60 Jul 9 18:02 pg_wal
drwx------ 2 postgres postgres 18 Jul 9 18:02 pg_xact
-rw------- 1 postgres postgres 88 Jul 9 18:02 postgresql.auto.conf
-rw------- 1 postgres postgres 26659 Jul 9 18:03 postgresql.conf
-rw------- 1 postgres postgres 53 Jul 9 18:05 postmaster.opts
-rw------- 1 postgres postgres 74 Jul 9 18:05 postmaster.pid
File and directory description:
pg_hba.conf：#认证配置文件，配置了允许哪些IP访问数据库，及认证方式等信息。
pg_ident.conf：#"ident"认证方式的用户映射文件。
PG_VERSION：#记录了数据库版本号信息。
postgresql.auto.conf：#作用同 postgresql.conf ，优先级高于 postgresql.conf，在数据库中通过alter命令更改的参数记录在此文件中。
postgresql.conf：#数据库实例主配置文件，基本上所有的数据库参数配置都在此文件中。
postmaster.opts：#记录数据库启动命令。
postmaster.pid：#数据库进程文件，数据库启动时被创建，关闭时消失。
base：#该目录包含数据库用户所创建的各个数据库，同时也包括postgres、template0和template1的pg_defaulttablespace。
global：#该目录包含集群范围的各个表和相关视图。(pg_database、pg_tablespace）
pg_dynshmem：#该目录包含动态共享内存子系统使用的文件。
pg_commit_ts：#该目录包含已提交事务的时间。
pg_logical：#该目录包含逻辑解码的状态数据。
pg_multixact：#该目录包含多事务状态数据。（等待锁定的并发事务）
pg_notify：#该目录包含LISTEN/NOTIFY状态数据。
pg_replslot：#该目录包含复制槽数据。
pg_snapshots：#该目录包含导出的快照。
pg_stat：#该目录包含统计子系统的永久文件。
pg_stat_tmp：#该目录包含统计子系统的临时文件。
pg_subtrans：#该目录包含子事务状态数据。
pg_tblspc：#该目录包含表空间的符号链接。
pg_twophase：#该目录包含预备事务的状态文件。
pg_wal：#该目录包含wal日志。
pg_xact：#该目录包含事务提交状态数据。
Log directory
The /app/pgsql/log/ path is customized. You can configure various logs of the database here. This environment only configures the database startup and shutdown logs.
[postgres@yuan log]$ cd /app/pgsql/log/
[postgres@yuan log]$ ll
total 4
-rw------- 1 postgres postgres 1006 Jul 9 21:21 postgres.log
The above is an introduction to the directory structure and its functions.
Detailed explanation of the configuration file postgresql.conf
After PostgreSql initialization is completed, a configuration file is generated under PGDATA postgresql.conf . Without making any changes, the database can be started smoothly after initialization is completed. Looking at the configuration file, it can be found that most of the configuration parameters have been commented out, and they It is built into the database by default, and only a few remaining parameters have not been commented out and have been rewritten by the system (different database versions may have different rewriting parameters). For example, the following parameters have been rewritten in pg 12.4. The default parameters can be used in the test environment, but when used in production, some optimization and configuration of the default parameters are required. Refer to Alibaba Cloud's best experiments and the pg official manual to learn and organize the configurations that can be used in the production environment.
max_connections = 100
shared_buffers = 128MB
dynamic_shared_memory_type = posix
max_wal_size = 1GB
min_wal_size = 80MB
log_timezone = 'PRC'
datestyle = 'iso, mdy'
timezone = 'PRC'
lc_messages = 'en_US.UTF-8'
lc_monetary = 'en_US.UTF-8'
lc_numeric = 'en_US.UTF-8'
lc_time = 'en_US.UTF-8'
default_text_search_config = 'pg_catalog.english'
Placement script
For the following script, just change a few parameters according to the shared_buffersactual effective_cache_sizeenvironment log_directory .
#connection control
listen_addresses = '*'
max_connections = 2000
superuser_reserved_connections = 10
tcp_keepalives_idle = 60
tcp_keepalives_interval = 10
tcp_keepalives_count = 10
password_encryption = md5
#memory management
shared_buffers = 16GB #推荐操作系统物理内存的1/4
max_prepared_transactions = 2000
work_mem = 8MB
maintenance_work_mem = 2GB
autovacuum_work_mem = 1GB
dynamic_shared_memory_type = posix
max_files_per_process = 24800
effective_cache_size = 32GB #推荐操作系统物理内存的1/2
#write optimization
bgwriter_delay = 10ms
bgwriter_lru_maxpages = 1000
bgwriter_lru_multiplier = 10.0
bgwriter_flush_after = 512kB
effective_io_concurrency = 0
max_worker_processes = 256
max_parallel_maintenance_workers = 6
max_parallel_workers_per_gather = 0
max_parallel_workers = 28
#wal optimization
synchronous_commit = remote_write
full_page_writes = on
wal_compression = on
wal_writer_delay = 10ms
wal_writer_flush_after = 1MB
commit_delay = 10
commit_siblings = 5
checkpoint_timeout = 30min
max_wal_size = 32GB
min_wal_size = 16GB
archive_mode = on
max_wal_senders = 64
wal_keep_segments = 15
wal_sender_timeout = 60s
max_replication_slots = 64
hot_standby_feedback = off
#log optimization
log_destination = 'csvlog'
logging_collector = on
log_directory = '/pg12.4/logs' # 日志存放路径，提前规划在系统上创建好
log_filename = 'postgresql-%a.log'
log_file_mode = 0600
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 1GB
#audit settings
log_min_duration_statement = 5s
log_checkpoints = on
log_connections = on
log_disconnections = on
log_error_verbosity = verbose
log_line_prefix = '%m [%p] %q %u %d %a %r %e '
log_statement = 'ddl'
log_timezone = 'PRC'
track_io_timing = on
track_activity_query_size = 2048
#autovacuum
autovacuum = on
vacuum_cost_delay = 0
old_snapshot_threshold = 6h
log_autovacuum_min_duration = 0
autovacuum_max_workers = 8
autovacuum_vacuum_scale_factor = 0.02
autovacuum_analyze_scale_factor = 0.01
autovacuum_freeze_max_age = 1200000000
autovacuum_multixact_freeze_max_age = 1250000000
autovacuum_vacuum_cost_delay = 0ms
#system environment
datestyle = 'iso, mdy'
timezone = 'Asia/Shanghai'
lc_messages = 'en_US.utf8'
lc_monetary = 'en_US.utf8'
lc_numeric = 'en_US.utf8'
lc_time = 'en_US.utf8'
default_text_search_config = 'pg_catalog.english'
Detailed description
Connection settings
- listen_addresses: Specifies the TCP/IP addresses on which the server listens for client connections. The default value is localhost, which only allows local connections.
- max_connections: Determines the maximum number of concurrent connections for the database. The default value is usually 100 connections. If the kernel settings do not support it (determined during initdb), it may be less than this number.
- superuser_reserved_connections: The number of connections reserved for super users. The default is 3 and cannot be less
max_connections.
memory settings
shared_buffers: The shared memory that the database server will use. The default is usually 128M. If the kernel settings do not support it (determined during initdb), it can be less. This setting must be at least 128 kilobytes. The recommended value for shared_buffers is 25% of system memory. Because PostgreSQL also relies on the operating system's high-speed buffers, setting shared_buffers to 40% more than system memory may cause a higher load.
max_prepared_transactions: Sets the maximum number of transactions that can be in the "prepared" state at the same time. Setting this parameter to zero (which is the default setting) will disable the prepared transactions feature. To use prepared transactions, set max_prepared_transactions to at least as large as max_connections.
work_mem: The maximum memory that can be used by a single query operation (such as sorting or hash table). The default value is 4MB. ORDER BY, DISTINCT and merge joins all use sort operations, hash joins, hash-based aggregation and hash-based aggregation. Hash tables are used in hash IN subquery processing.
maintenance_work_mem: The maximum memory used in maintenance operations (such as VACUUM, CREATE INDEX, and ALTER TABLE ADD FOREIGN KEY). Its default value is 64M. Larger settings can improve the performance of cleaning and restoring database dumps.
autovacuum_work_mem: The maximum amount of memory that each autovacuum worker process can use. Its default value is -1, which means that the value of maintenance_work_mem is used instead. It is recommended to allocate it separately, because the resources allocated by maintenance_work_mem will also be used for index building and other operations.
dynamic_shared_memory_type: The memory management method used by the server. Possible values are posix (for POSIX shared memory allocated using shm_open), sysv (for System V shared memory allocated via shmget), windows (for Windows shared memory), and mmap (used for shared memory stored in the data directory) Memory mapped files simulate shared memory). Not all values are supported on all platforms, the first supported option on a platform is its default value. The mmap option is not the default on any platform, and its use is generally discouraged because the operating system will repeatedly write modified pages back to disk, thereby increasing the I/O load on the system. However, it is useful when the pg_dynshmem directory is stored on a RAM disk or when no other shared memory functionality is available.
effective_cache_size: The planner's estimate of the effective disk buffer size available for a single query. Higher values will make index scans more likely to be used, lower values will make sequential scans more likely to be used. This parameter has no effect on the size of shared memory allocated by PostgreSQL, nor does it preserve kernel disk buffering. It is used for estimation purposes only. The default value is 4GB, and the recommended value is 50% of system memory or greater.
IO settings
bgwriter_delay: Delay between rounds of background writer activity. In each round, the writer issues writes for a certain number of dirty buffers, after which it sleeps for bgwriter_delay and repeats. When there are no dirty buffers in the buffer pool, it will sleep longer regardless of bgwriter_delay. The default value is 200ms.
bgwriter_lru_maxpages: No more than this many buffers will be written out by the background writer in each round. Setting this parameter to zero disables background writing. The default value is 100 buffers.
bgwriter_lru_multiplier: The average number of recently required buffers multiplied by bgwriter_lru_multiplier can be used to estimate the number of buffers that will be needed in the next round. Dirty buffers will be written out until there are many clean and reusable buffers (however, the number of buffers written out in each round will not exceed bgwriter_lru_maxpages). Therefore, a setting of 1.0 represents a "just enough" strategy that writes just the number of buffers that match the predicted values. A larger value can provide some buffering from peak demand. The default value is 2.0.
effective_io_concurrency: If this value is set, disk read-ahead will be invalid. Both sequential scans and index scans can use disk read-ahead. It is recommended to turn it off. The default value is 1.
max_worker_processes: The maximum number of background processes that the system can support. The default value is 8. When changing this value, consider also adjusting max_parallel_workers, max_parallel_maintenance_workers, max_parallel_workers_per_gather.
max_parallel_workers: Set the maximum number of parallelism supported by the system. The default value is 8. Note that setting this value greater than max_worker_processes will have no effect because parallel worker processes are taken out from the worker process pool established by max_worker_processes. .
max_parallel_maintenance_workers: The maximum number of parallels that can be started by a single utility command. The utility command that currently supports the use of parallel workers is CREATE INDEX, and only when building B-tree indexes in parallel, and VACUUM does not have a FULL option. Parallel workers are taken from the process pool created by max_worker_processes, the number is controlled by max_parallel_workers, the default value is 2.
max_parallel_workers_per_gather: Set the maximum number of parallel queries allowed. Parallel queries may consume more resources than non-parallel queries. Setting this value to 0 will disable parallel query execution. The default value is 2.
wal_compression: When this parameter is on, if full_page_writes is on (the default value is on) or during a basic backup, the PostgreSQL server will compress the full page image written to the WAL. Compressed page images will be decompressed during WAL replay. The default value is off. Only superusers can change this setting. Turning this parameter on can reduce the space occupied by WAL without risking unrecoverable data corruption, but at the cost of additional CPU overhead for compression during WAL recording and during WAL replay. Unzip.
wal_writer_delay: Specifies how frequently the WAL writer flushes WAL, in time units. After flushing WAL, the writer will sleep for the length of time given by wal_writer_delay, unless it is woken up early by an asynchronously committed transaction. If the latest flush occurs before wal_writer_delay and is less than the value of wal_writer_flush_after WAL, then WAL will only be written to the operating system and will not be flushed to disk. The default value is 200ms.
commit_delay: commit_delay adds a time delay before a WAL flush is initiated. If the system load is high enough that additional transactions are ready to commit within a given interval, group commit throughput can be improved by allowing more transactions to commit with a single WAL flush. However, it also increases the latency of each WAL flush to a maximum of commit_delay. Because a delay is wasted if no other transactions are ready to commit, a delay will only be performed if there are at least commit_siblings (default 5) other active transactions when a flush is about to be initiated. Additionally, if fsync is disabled, no delay will be performed.
checkpoint_timeout: The maximum time between automatic WAL checkpoints. The reasonable range is between 30 seconds and 1 day. The default is 5min. Increasing the value of this parameter increases the time required for crash recovery.
max_wal_size: The maximum size that WAL is allowed to grow to between automatic WAL checkpoints. This is a soft limit and the WAL size may exceed max_wal_size under special circumstances, such as under heavy load, archive_command failure or a high wal_keep_size setting. The default is 1 GB. Increasing this parameter may increase the time required for crash recovery.
min_wal_size: As long as WAL disk usage remains below this setting, old WAL files are always recycled for future use at checkpoints, rather than being deleted directly. This can be used to ensure that enough WAL space is reserved to cope with peaks in WAL usage, such as running large batch jobs. If the value is specified without units, it is in megabytes, which defaults to 80 MB.
archive_mode: When archive_mode is enabled, completed WAL segments can be sent to archive storage by setting the archive_command command. In addition to off for disabling, there are two modes: on and always. During normal operation, there is no difference between the two modes, but when set to always, the WAL archiver is also enabled in archive recovery or fallback mode. In always mode, all files restored from the archive or transferred by streaming copy will be archived (again). When wal_level is set to minimal, archive_mode cannot be enabled.
max_replication_slots: The maximum number of replication slots that the server can support. The default value is 10. Setting this to a value with fewer replication slots than currently available will prevent the server from starting. Additionally, to allow use of replica slots, wal_level must be set to replica or higher.
synchronous_commit parameter description
There are 5 options: on, off, local, remote_write, and remote_apply.
Single instance environment:
on: When the database commits a transaction, wal first writes to the wal buffer and then to the wal log file. Setting it to on means that when submitting a transaction, you need to wait for the local wal to write to the wal log before returning success to the client. On is the default setting, the database is very secure, but performance is compromised.
local: The meaning of local is similar to on, which means that when submitting a transaction, you need to wait for the local wal to be written before returning success to the client.
off: When the database commits a transaction, it does not need to wait for the local wal buffer to be written to the wal log, and then returns success to the client. Setting it to off will bring some risks to the database: a small number of the latest submitted transactions may be lost when the database goes down, and the database restarts. Later, these transactions will be considered to have terminated abnormally and will be rolled back. It is suitable for scenarios where database accuracy is not required and database performance is pursued.
Streaming replication environment:
on: Indicates that when the streaming replication master database submits a transaction, it needs to wait for the standby database to receive the wal log stream sent by the primary database and write it into the wal file before returning success to the client. Simply put, on means that the local wal has been placed on the disk, and the standby database The wal has also been placed on the disk, and there are two persistent wals, but the backup database has not been redone at this time. This option results in higher transaction response times.
remote_write: indicates that when the streaming replication master database submits a transaction, it needs to wait for the standby database to receive the wal log stream sent by the primary database and write it into the standby node operating system cache, and then returns success to the client. In this case, the standby database is shut down abnormally. There is no risk of losing the transferred wal log. However, if the standby operating system crashes abnormally, there is a risk of losing the transferred wal. At this time, wal may not be completely written into the standby node wal file. Simply put, remote_write means local The wal has been placed on the disk, and the wal of the standby database is still in the cache of the standby operating system, which means that there is only one persistent wal. This option results in lower transaction response times.
remote_apply: Indicates that when the streaming replication master database submits a transaction, it needs to wait for the standby database to receive the wal stream sent by the primary database and write it into the wal file. At the same time, the standby database has completed the redo before returning success to the client. Simply put, remote_apply means local WAL has been placed on disk, and the standby database WAL has been placed on disk and has been redone. This setting ensures that there are two persistent WAL copies, and the standby database has also been redone. This option results in the highest transaction response time.
Log settings
log_destination: There are three output methods, stderr, csvlog, syslog; eventlog is also supported on Windows. The default is stderr. If csvlog is used, logging_collector must be enabled. You can also use csvlog and stderr at the same time, and logs in both formats will be recorded.
logging_collector: Log collector, it is a background process that captures log messages sent to stderr, and it redirects these messages to the log file. The default is OFF.
log_directory: Log saving path. When logging_collector is enabled, this parameter determines the directory in which the log file will be created.
log_filename: log name format, the default is postgresql-%Y-%m-%d_%H%M%S.log.
log_file_mode: The default permission is 0600, which means that only the server owner can read or write the log file. Other commonly used setting is 0640, which allows members of the owner's group to read the file. Note, however, that you need to modify log_directory to store the files somewhere outside the cluster data directory to take advantage of this setting. In any case, it is unwise to make log files readable by anyone because the log files may contain sensitive data.
log_truncate_on_rotation: When logging_collector is enabled, this parameter will cause PostgreSQL to truncate (overwrite rather than append) any existing log files with the same name. However, truncation only occurs when a new file is opened due to time-based rotation, not size-based rotation. If closed, in all cases previously existing files will be appended.
log_rotation_age: When logging_collector is enabled, this parameter determines the maximum amount of time a single log file is used before a new log file is created. The default is 24 hours. Setting this parameter to zero will disable time-based creation of new log files.
log_rotation_size: When logging_collector is enabled, this parameter determines the maximum size of an individual log file. When this amount of data is sent to a log file, a new log file will be created. The default value is 10M. Set to zero to disable size-based creation of new log files.
log_min_duration_statement: The time threshold for recording slow SQL. SQL exceeding this time will be recorded in the log. The default value is -1, and slow SQL will not be recorded.
log_checkpoints: Controls whether checkpoints and restart points are recorded in the server log. Some statistics are also included in the log message, including the data written to the buffer and the time spent writing them. The default value is off.
log_connections: Controls whether connection information is logged. Connection attempts to the server are logged, and successful completion of client authentication is also logged. It cannot be changed during the session. The default is off.
log_disconnections: Controls whether session terminations are logged. The log output provides information similar to log_connections, but plus the duration of the session, which cannot be changed during the session and defaults to off.
log_error_verbosity: Valid values are TERSE, DEFAULT, and VERBOSE. TERSE excludes logging DETAIL, HINT, QUERY, and CONTEXT error messages. VERBOSE output includes the SQLSTATE error code and the source code file name, function name and line number where the error occurred. The default is DEFAULT.
log_line_prefix: Set the content in the log. The default value is ’%m [%p] 'to record the timestamp and process ID.
log_statement: Control which SQL statements are logged. Valid values are none (off), ddl, mod, and all (all statements). mod logs all ddl statements, plus data modification statements such as INSERT, UPDATE, DELETE, TRUNCATE, and COPY FROM. PREPARE, EXECUTE, and EXPLAIN ANALYZE are also logged if they contain commands of the appropriate type. The default is none.
log_timezone: Sets the time zone for timestamps written in server logs. The default value is GMT.
log_filename format character description
%a #星期的英文单词的缩写：如星期一， 则返回 Mon
%A #星期的英文单词的全拼：如星期一，返回 Monday
%b #月份的英文单词的缩写：如一月， 则返回 Jan
%B #月份的引文单词的缩写：如一月， 则返回 January
%c #返回datetime的字符串表示，如03/08/15 23:01:26
%d #返回的是当前时间是当前月的第几天
%f #微秒的表示： 范围: [0,999999]
%H #以24小时制表示当前小时
%I #以12小时制表示当前小时
%j #返回 当天是当年的第几天 范围[001,366]
%m #返回月份 范围[0,12]
%M #返回分钟数 范围 [0,59]
%P #返回是上午还是下午–AM or PM
%S #返回秒数 范围 [0,61]。。。手册说明的
%U #返回当周是当年的第几周 以周日为第一天
%W #返回当周是当年的第几周 以周一为第一天
%w #当天在当周的天数，范围为[0, 6]，6表示星期天
%x #日期的字符串表示 ：03/08/15
%X #时间的字符串表示 ：23:22:08
%y #两个数字表示的年份 15
%Y #四个数字表示的年份 2015
%z #与utc时间的间隔 （如果是本地时间，返回空字符串）
%Z #时区名称（如果是本地时间，返回空字符串）
log_line_prefix format character description
%a #应用名
%u #用户名
%d #数据库名
%r #远程主机名或 IP 地址，以及远程端口
%h #远程主机名或 IP 地址
%b #后端类型
%p #进程 ID
%t #无毫秒的时间戳
%m #带毫秒的时间戳
%n #带毫秒的时间戳（作为 Unix 时代）
%i #命令标签：会话当前命令的类型
%e #SQLSTATE 错误代码
%c #会话 ID：见下文
%l #对每个会话或进程的日志行号，从 1 开始
%s #进程开始的时间戳
%v #虚拟事务 ID (backendID/localXID)
%x #事务 ID （如果未分配则为 0）
%q #不产生输出，但是告诉非会话进程在字符串的这一点停止；会话进程忽略
%% #纯文字%
autovacuum settings
autovacuum: Controls whether the server runs the automatic cleaning launcher background process. The default is on, but for automatic cleaning to work properly, track_counts needs to be enabled (enabled by default). This parameter can only be set in the postgresql.conf file or on the server command line. Automatic cleaning can be disabled for a table by changing the table storage parameters. Note that even if this parameter is disabled, the system will initiate a cleanup process when needed to prevent transaction ID rollback.
old_snapshot_threshold: Set the minimum time that a query snapshot can be used to avoid the risk of "snapshot too old" errors when using snapshots. Data that exceeds this threshold time will be cleared, which can help prevent long-term snapshots from being used. Snapshot inflation, the default value is -1 (disables this feature), effectively sets the snapshot age limit to infinity.
log_autovacuum_min_duration: Automatic cleaning actions that exceed this time threshold will be logged. Setting this parameter to 0 will record all automatic cleaning actions. The default value is -1 (disables the recording of automatic cleaning actions). Additionally, when this parameter is set to any value except -1, if an automatic cleanup action is skipped due to a lock violation or concurrent deletion, a message will be logged for this. Turning this parameter on is useful for tracking automatic cleanup activity, but this setting can be overridden for individual tables by changing the table's storage parameters.
autovacuum_max_workers: Set the maximum number of autovacuum processes (except the autovacuum initiator) that can run simultaneously. The default value is 3.
autovacuum_vacuum_scale_factor: The proportion of dml that triggers vacuum automatic cleaning operations. The default value is 0.2. When the dml operations on the table occupy 20% of the table data volume, the vacuum automatic cleaning operation is triggered. In order to prevent tables with small data volumes from being cleaned frequently, it is related to autovacuum_vacuum_threshold ( Change the default value of the parameter to 50. Vacuum automatic cleaning will be triggered only when at least 50 pieces of data in the table are sent to the dml operation.) The parameters work together.
autovacuum_analyze_scale_factor: The DML ratio that triggers the automatic vacuum analyze operation. The default value is 0.1. When the DML operation on the table occupies 10% of the table data volume, the automatic vacuum analyze operation is triggered. In order to prevent tables with small data volumes from being analyzed frequently, it is related to autovacuum_analyze_threshold ( Change the default value of the parameter to 50. Vacuum (automatic analyze) will be triggered only when at least 50 pieces of data in the table are sent to the dml operation. The parameters work together.
autovacuum_freeze_max_age: The maximum value of pg_class.relfrozenxid of a table. If this value is exceeded, the xid will be reset. The default value is 200 million. Note that even if automatic cleaning is disabled, the system will initiate an automatic cleaning process to prevent rollback.
autovacuum_multixact_freeze_max_age: The maximum value of pg_class.relminmxid of a table. If this value is exceeded, the xid will be reset. The default value is 400 million. Note that even if automatic cleaning is disabled, the system will initiate an automatic cleaning process to prevent rollback.
autovacuum_vacuum_cost_delay: Specifies the cost delay value used in automatic VACUUM operations. If -1 (default value) is specified, the vacuum_cost_delay value (default value 2ms) is used.
Additional information
Since each business table in the production environment has different functions, frequency of use, growth rate of "dead tuples", etc., it is recommended to set parameter values separately for important production business tables based on business conditions.
-
For tables with particularly frequent dml operations, make settings similar to the following:
ALTER TABLE mytable SET (autovacuum_vacuum_scale_factor = 0.01);
-
For index fields and tables with particularly frequent DML operations, make settings similar to the following:
ALTER TABLE mytable SET (fillfactor=80);
-
Only insert into the database table and make settings similar to the following:
ALTER TABLE mytable SET (autovacuum_freeze_max_age = 10000000);
System environment settings
datestyle: Sets the display format for date and time values, as well as rules for interpreting ambiguous date input values. For historical reasons, this variable contains two separate parts: the output format declaration (ISO, Postgres, SQL, or German), and the input/output year/month/day order (DMY, MDY, or YMD). These can be set independently or together. The keywords Euro and European are synonyms of DMY; the keywords US, NonEuro and NonEuropean are synonyms of MDY. The built-in defaults are ISO, MDY, but initdb will initialize the configuration file with settings corresponding to the selected lc_time zone behavior.
timezone: Set the time zone used to display and interpret timestamps. The built-in default is GMT, but this is usually overridden in postgresql.conf; initdb will install a setting corresponding to its system environment.
lc_messages: Set the language for message display. Acceptable values are system-dependent. If this variable is set to the empty string (default), then the value will be inherited from the server's execution environment in a system-dependent manner.
On some systems, this zone classification does not exist. You can still set this variable, it just won't have any effect. Likewise, translation messages for the desired language may not exist. In this case, you will still continue to see messages in English.
Only superuser can change this setting. Because it affects both the messages sent to the server log and the client. An incorrect value may reduce the readability of the server log.
lc_monetary: Sets the area used to format monetary amounts, such as using the to_char function family. Acceptable values are system-dependent. If this variable is set to the empty string (default), then the value will be inherited from the server's execution environment in a system-dependent manner.
lc_numeric: Set the area used to format numbers, such as using the to_char function family. Acceptable values are system-dependent. If this variable is set to the empty string (default), then the value will be inherited from the server's execution environment in a system-dependent manner.
lc_time: Set the area used for formatting dates and times, such as using the to_char function family. Acceptable values are system-dependent. If this variable is set to the empty string (default), then the value will be inherited from the server's execution environment in a system-dependent manner.
default_text_search_config: Selects the text search configuration used by those text search function variants that do not have an explicit parameter to specify the configuration. The built-in default is pg_catalog.simple, but if a matching region can be identified, initdb will use the configuration corresponding to the selected lc_ctype Regional settings initialization configuration file.