不能直接用SQL触发器同步ES日志，因PG触发器仅支持PL/pgSQL/C函数，无法发起HTTP请求；硬写curl不可靠、不安全且阻塞事务。正确做法是触发器调用pg_notify发通知，由外部Worker监听并异步处理。
不能直接用 SQL 触发器同步 Elasticsearch 日志 —— PostgreSQL 的 TRIGGER 只能在数据库内执行 PL/pgSQL 或 C 函数，无法发起 HTTP 请求或调用外部服务。硬写 curl 或 http_get 不仅不可靠、不安全，还会阻塞事务、拖慢写入性能。
为什么不能在触发器里直接调用 ES API
PostgreSQL 触发器运行在事务上下文中，所有操作必须满足 ACID。而向 Elasticsearch 发起网络请求：
- 可能超时或失败，导致整个事务回滚（哪怕业务数据已合法）
- 没有重试、幂等、序列化保障，重复触发会写入脏数据
- 原生不支持 HTTP 客户端；第三方扩展如
http（由pgxn提供）需手动编译安装，且不兼容云托管 PG（如 RDS、Aurora） - 日志类数据通常不要求强一致，但触发器强耦合会把搜索延迟引入核心写路径
正确做法：用 NOTIFY + 外部 Worker 解耦
真正可行的方案是让触发器只发通知，由独立进程监听并异步处理。这是 PostgreSQL 官方推荐的轻量级事件分发机制。
关键步骤：
- 在触发函数中调用
pg_notify('es_sync', payload::text)，payload 是 JSON 字符串（含表名、操作类型、主键） - Worker 进程用
LISTEN es_sync持久连接，收到消息后解析 payload，查出完整记录，再调用 ES 的_update_by_query或_bulk - Worker 必须自己实现幂等逻辑：例如用
WHERE id = ?更新 ES 文档，或在 payload 中加入updated_at时间戳比对 - 不要在触发器里查完整行数据（
NEW.*传太多字段会增大 NOTIFY 负载），只传必要标识字段（如id）
容易踩的坑：WAL 日志配置缺失
如果你后续想升级到更稳定的 CDC 方案（比如 PGSync 或 Debezium），会发现连启动都失败 —— 因为缺基础配置：
-
wal_level = logical：必须开启，否则逻辑复制和变更捕获不可用 -
max_replication_slots = 10：每个同步任务需占用一个 slot，设太小会导致 slot 溢出、WAL 被清理、同步中断 -
max_slot_wal_keep_size = 100GB：防止 WAL 过早回收，尤其在 Worker 崩溃未及时消费时 - 这些参数改完需重启 PostgreSQL，不是
SET就生效
真正要同步日志类数据，优先考虑用 Filebeat + Logstash 或直接从应用层打结构化日志到 ES；若坚持从 PG 出发，触发器只是起点，NOTIFY 是必经跳板，而 Worker 的容错设计才是成败关键 —— 它不写在数据库里，却决定了整个链路是否可靠。
