PostgreSQL 有一组以 _min_messages 结尾的 GUC，初学者最常踩坑的就是 client_min_messages。原因很简单——名字里带 "messages"，直觉上以为它在控制服务器日志的详细程度，实际上它只决定你的会话能看到什么。搞反了这条线，调半天日志级别还是看不到想要的输出，或者反过来，把本该记录到日志的 NOTICE 级别信息给"静默"了，排查问题时一头雾水。
它管的是"前台"，不是"后台"
client_min_messages 的作用域是 session 级别，影响的是客户端连接收到的消息。当你执行一条 SQL，PostgreSQL 可能返回几种非结果集的消息：NOTICE、WARNING、DEBUG……这个参数决定哪些级别会被发送到你的客户端，低于设定级别的消息直接被丢弃，客户端根本收不到。
和它容易混淆的是 log_min_messages——这才是控制服务器写日志文件的那个参数。两个参数的默认值也不一样：
| 参数 | 默认值 | 控制对象 |
|---|---|---|
client_min_messages |
notice |
客户端会话看到的消息 |
log_min_messages |
warning |
服务器日志文件记录的消息 |
默认情况下，NOTICE 会出现在你的 psql 终端里，但不会写入服务器日志；WARNING 则两边都会出现。这个设计是合理的——NOTICE 级别的东西（比如创建对象时的隐式索引提示）对交互式用户有用，但没必要持久化到磁盘。
常见的三个坑
坑一：想减少日志体积，去调 client_min_messages。
结果日志文件毫无变化，只是自己的终端变安静了。正确做法是调 log_min_messages。
坑二：把 client_min_messages 设到 error，以为这样更"干净"。
WARNING 和 NOTICE 全被屏蔽。你在交互式会话里看不到任何警告，比如 DELETE 没有 WHERE 条件时的 WARNING 提示也消失了，等出了数据事故才发现原来数据库一直在提醒你。
坑三：在连接池或应用层全局设了极低级别，开发环境也看不到调试信息。
ORM 或连接池中间件可能统一设置了 client_min_messages = warning，开发时想看 DEBUG 级别的查询计划提示，怎么调都不出来——因为连接建立时参数就已经被锁定了。
实际操作：看清两个参数的区别
下面这段可以直接在 psql 里运行，观察 client_min_messages 和 log_min_messages 的不同行为：
-- 先看当前设置
SHOW client_min_messages;
SHOW log_min_messages;
-- 创建一个会触发 NOTICE 的场景：在已有表上创建重复索引
CREATE TABLE demo_msg (id int PRIMARY KEY);
-- 这条会触发 NOTICE: "relation "demo_msg_pkey" already exists"
CREATE UNIQUE INDEX ON demo_msg (id);
-- 现在把客户端消息级别调高，屏蔽 NOTICE
SET client_min_messages = warning;
-- 再执行同样的操作——终端不再显示 NOTICE
CREATE UNIQUE INDEX ON demo_msg (id);
-- (终端无任何提示)
-- 但服务器日志是否记录？取决于 log_min_messages
-- 如果 log_min_messages <= notice，日志里仍然有记录
-- 如果 log_min_messages > notice，日志里也没有
-- 恢复默认
RESET client_min_messages;
-- 清理
DROP TABLE demo_msg;
如果你想确认服务器日志是否记录了这条 NOTICE，需要去查看 PostgreSQL 的日志文件（路径取决于 log_directory 和 log_filename 设置），而不是在终端里找：
# 查看当前日志目录
psql -c "SHOW log_directory;"
# 在数据目录下找日志（常见路径）
# Debian/Ubuntu 系统通常在 /var/log/postgresql/
# 其他安装可能在 $PGDATA/log/
tail -20 /var/log/postgresql/postgresql-*.log | grep -i "already exists"
按场景选择级别
client_min_messages 的可选值从低到高：debug5 → debug4 → debug3 → debug2 → debug1 → log → notice → warning → error。设为某级别后，低于该级别的消息不再发送到客户端。
几个实用建议：
- 交互式开发/调试：设为
notice（默认值）或偶尔降到log，能看到 PL/pgSQL 的RAISE LOG输出，方便追踪函数执行路径。 - 生产应用连接：设为
warning就够了。应用不需要 NOTICE 级别的提示信息，但 WARNING 必须看到——它往往意味着即将出问题。 - 永远不要设为
error：屏蔽 WARNING 的代价远大于减少一点终端噪音的收益。 - 需要 DEBUG 信息时，用会话级
SET，不要改全局配置：
-- 临时开启 DEBUG1，只影响当前会话
SET client_min_messages = debug1;
-- 做完调试后恢复
RESET client_min_messages;
一条检查清单
下次遇到"消息看不到"的问题，先过一遍这个流程：
- 你要的消息是给终端/应用看的，还是给日志文件看的？前者查
client_min_messages，后者查log_min_messages。 - 消息的级别是什么？
RAISE NOTICE产生的是 NOTICE，RAISE WARNING产生的是 WARNING——级别要对得上。 - 参数是在哪里设的？
ALTER SYSTEM SET改的是全局，SET改的是会话，连接池可能有自己的默认值。用SHOW在当前会话里确认实际生效值。 - 如果你用的是 ORM 或连接池，确认它没有在连接建立时悄悄覆盖你的设置。
把 client_min_messages 和 log_min_messages 当成两条独立的管道——一条通向你的屏幕，一条通向磁盘——就不会再混着调了。