PostgreSQL 的日志配置看起来只是几个 GUC 参数，实际却关系到日志是否丢失、不同进程的输出是否互相打乱，以及配置什么时候真正生效。log_destination 决定日志要写到哪里，logging_collector 则负责启动一个基于管道的日志收集进程，把服务器进程产生的消息集中处理。
其中一个容易被忽略的操作边界是：打开 logging_collector 需要重启 PostgreSQL，而不是简单执行一次 reload。生产环境如果计划启用它，应该把重启安排在业务负载到来之前。
两个 GUC，各自负责什么
log_destination 描述日志输出目标。实际配置时，可以选择标准错误输出，也可以组合多个目标，例如把日志交给收集器生成文件，同时保留其他输出方式。常见取值包括：
stderr：写入标准错误输出。启用日志收集器后，收集器可以接管这些消息。csvlog：生成结构化的 CSV 日志，便于后续导入或解析，但需要日志收集器。syslog：发送到系统日志服务。eventlog：Windows 环境中的事件日志目标。
logging_collector 是一个布尔开关。启用后，PostgreSQL 会启动一个小型的、基于管道的后台收集进程。它的价值不只是“把日志写进文件”：集中收集可以减少多个服务器进程同时写日志时出现的消息丢失和内容交错问题。
这两个参数不是同一层面的设置：log_destination 选择输出方向，logging_collector 决定 PostgreSQL 是否启动收集机制。配置了 csvlog 却没有收集器，通常就是一个明显的配置错误。
为什么开启收集器必须重启
日志收集器需要在 PostgreSQL 服务器启动阶段建立管道、创建并管理后台进程。因此，logging_collector 的生效级别是 postmaster：修改配置文件或执行 ALTER SYSTEM 后，现有服务器进程不会自动启动收集器。
这与很多可以通过 reload 生效的日志参数不同。可以用下面的查询确认当前值和生效上下文：
SELECT name, setting, context, pending_restart
FROM pg_settings
WHERE name IN ('logging_collector', 'log_destination');
如果 logging_collector 的 pending_restart 显示为 on，说明配置已经写入，但仍需重启实例。不要把 pg_reload_conf() 当成重启的替代品：它只能重新读取可以动态加载的配置，无法凭空创建启动阶段才需要的收集进程。
一个可以直接改造的配置流程
下面示例假设 PostgreSQL 由 systemd 管理，并希望启用收集器，同时生成普通标准错误日志和 CSV 日志。请根据实际服务名替换 postgresql；有些发行版使用带版本号的服务名。
先通过 SQL 写入配置：
sudo -u postgres psql -d postgres <<'SQL'
ALTER SYSTEM SET logging_collector = 'on';
ALTER SYSTEM SET log_destination = 'stderr,csvlog';
SQL
然后检查配置文件是否已经记录了目标值：
sudo -u postgres psql -d postgres -c \
"SELECT name, setting, context, pending_restart FROM pg_settings WHERE name IN ('logging_collector', 'log_destination');"
确认维护窗口后重启：
sudo systemctl restart postgresql
重启完成后，再验证收集器已经运行：
sudo -u postgres psql -d postgres -c \
"SELECT name, setting, pending_restart FROM pg_settings WHERE name IN ('logging_collector', 'log_destination');"
预期结果是 logging_collector 为 on，pending_restart 不再提示待重启。日志文件的具体目录和轮转策略还取决于其他 PostgreSQL 日志参数以及操作系统服务配置，不能仅凭 log_destination 推断出最终文件路径。
如果暂时只想验证配置是否能被读取，也可以执行：
SELECT pg_reload_conf();
但对 logging_collector 而言，这一步不会让收集器在当前实例中启动；它只适合处理那些支持 reload 的参数。
生产环境中的几个判断
启用收集器前，先确认日志消费链路。数据库本地文件、系统日志服务和容器标准输出的运维方式不同。容器环境通常已经有平台日志采集器，此时是否启用 PostgreSQL 的文件收集器，需要结合运行时的日志抓取方式、磁盘容量和轮转策略判断。
如果选择 csvlog，下游可以按列解析日志，比依赖自由文本正则更稳定；代价是需要处理 CSV 格式、字段转义和日志文件生命周期。若只是人工排查故障，stderr 往往更容易直接阅读。
还要把重启要求纳入变更流程：
- 在低峰期执行，而不是等到日志问题已经影响排障时才开启。
- 先确认磁盘、日志轮转和采集代理不会因为新输出目标而失控。
- 用
pg_settings.pending_restart检查“配置已写入但尚未生效”的状态。 - 重启后从实际日志出口验证内容，而不只看 SQL 参数值。
- 不要把收集器当作完整的日志保留方案；保留周期、权限、脱敏和集中存储仍需单独设计。
结语：先决定出口，再安排重启
理解这两个 GUC 的关键，是把“日志写到哪里”和“谁负责收集日志”分开考虑。log_destination 负责表达目标，logging_collector 负责启用 PostgreSQL 内部的收集进程。只修改前者不一定需要重启，但启用后者必须计划重启。
一个实用的上线检查顺序是：确认目标格式，检查收集与轮转链路，写入配置，查看 pending_restart，安排重启，最后从实际日志中验证。这样配置日志时，问题会从“参数看起来对不对”变成一条可以观察和验收的运维流程。