PostgreSQL 18 参数速查：默认值、生效方式、改哪一层

2026-11-10 #数据库

调参出错，一半是记错默认值，另一半是改错了层：把会话级参数写进配置文件以为全局生效，或者改完不重启就以为生效了。下面这张表把两件事放在一起，数字取自 18.6 的出厂值。

1. 常改参数

参数	默认值	context（改动方式）
`shared_buffers`	128MB	postmaster（重启）
`max_connections`	100	postmaster（重启）
`work_mem`	4MB	user（会话级）
`maintenance_work_mem`	64MB	user（会话级）
`effective_cache_size`	4GB	user（会话级，只影响成本估算）
`random_page_cost`	4	user（会话级）
`effective_io_concurrency`	16	user（会话级）
`io_method`	worker	postmaster（重启）
`io_workers`	3	sighup（reload）
`io_combine_limit`	128kB	user（会话级）
`wal_level`	replica	postmaster（重启）
`max_wal_size`	1GB	sighup（reload）
`checkpoint_timeout`	300s	sighup（reload）
`autovacuum_max_workers`	3	sighup（reload）
`log_min_duration_statement`	-1（关闭）	superuser
`statement_timeout`	0（不限）	user（会话级）
`timezone`	容器内多为 Etc/UTC	user（会话级）

2. context 的四种含义

context	改完怎么生效	典型参数
`postmaster`	改配置文件后重启实例	`shared_buffers`、`max_connections`、`io_method`
`sighup`	`pg_reload_conf()` 或 `pg_ctl reload`	`max_wal_size`、`io_workers`
`user`	会话内 `SET` 立即生效；配置文件里的值作为默认并影响新会话	`work_mem`、`statement_timeout`
`superuser`	同上，但只允许超级用户改	`log_min_duration_statement`

sighup 类改完，pg_settings.pending_restart 应该是 f；postmaster 类改完它是 t，此时改的值还没生效。

3. 一条 SQL 导出现状

SELECT name, setting, unit, context, pending_restart
FROM pg_settings
WHERE name IN ('shared_buffers','work_mem','max_connections','io_method',
               'io_workers','effective_io_concurrency','max_wal_size')
ORDER BY name;

把它和上表对一遍，就知道自己这台机器被谁改过。

4. 三个坑

改错层。ALTER SYSTEM SET work_mem = '64MB' 只改了默认值，已连接的会话仍是旧值；要立刻生效得在会话里 SET，或者重连。

改完没确认。postmaster 类参数需要重启，用 pending_restart 判断，不要靠猜。

版本改名。io_workers 是 18.x 的名字（默认 3）；19 的文档把它拆成 io_min_workers（默认 2）和 io_max_workers（默认 8），还加了 io_worker_idle_timeout。在 18.6 上执行 SHOW io_min_workers 会直接报 unrecognized configuration parameter，所以照文档调参之前先 SHOW 一下名字在不在。

小结

调参前先确认三件事：默认值是多少、这个参数属于哪一层、改完要不要重启。三条都在 pg_settings 里查得到（setting、context、pending_restart），比记在脑子里可靠。

另外提醒一句：容器镜像的出厂值和文档一致，但镜像的启动参数、ALTER SYSTEM、以及编排文件里的环境变量都会覆盖它。上面的数字来自一个没有额外参数的 postgres:18 容器，你那台未必一样。

数据来源与检索时间

检索时间 2026-11-10。默认值与 context 为本机 18.6 实测（pg_settings），并与文档核对。

来源	URL	对应数据
PostgreSQL 18 文档《19.4 Resource Consumption》	https://www.postgresql.org/docs/18/runtime-config-resource.html	`shared_buffers` 128MB、`work_mem` 4MB、`maintenance_work_mem` 64MB、`effective_cache_size` 4GB、`io_method`/`io_workers` 语义
PostgreSQL 18 文档《19.5 Write Ahead Log》	https://www.postgresql.org/docs/18/runtime-config-wal.html	`wal_level` 默认 replica、`max_wal_size` 1GB、`checkpoint_timeout` 5 分钟
PostgreSQL 19 文档《19.4 Resource Consumption》	https://www.postgresql.org/docs/19/runtime-config-resource.html	`io_min_workers` 2 / `io_max_workers` 8 / `io_worker_idle_timeout`，用于版本注记

核验说明

表中数值取自两个 postgres:18（18.6）容器：一个是无额外启动参数的出厂实例，一个为测试报错设了 -c max_connections=10。后者只用于取报错文本，max_connections 的默认值 100 来自前者。
未做的事：没有逐一验证每个参数改动后的实际效果（那是各篇文章的事），这里只保证默认值与 context 准确。

#数据库