触发器中调用http_post或dblink_exec可行但强耦合事务，失败将导致源操作回滚；需捕获异常、复用连接、避免shell_exec等高危操作，并权衡一致性与可用性。
直接用触发器调用外部函数（比如 http_post 或 dblink_exec）是可行的，但必须明确：这类调用默认在事务内同步执行，一旦失败会导致源表操作回滚——这不是“尽力而为”的同步，而是强一致性耦合。你得先决定要的是可靠性优先，还是可用性优先。
触发器里调用 http_post 为什么常失败？
pgsql-http 的 http_post 在事务提交前就发请求，但网络超时、目标服务不可达、SSL 验证失败等都会让函数抛出异常，进而中止整个 INSERT/UPDATE 事务。
- 常见错误现象：
ERROR: could not connect to server: Connection refused或ERROR: HTTP request failed: timeout - 使用场景：适合下游系统稳定、延迟敏感低、且能接受源库写入阻塞的场景（如内部微服务）
- 规避建议：
– 必须加BEGIN ... EXCEPTION捕获异常，否则一错全挂
– 不要在BEFORE触发器里调用，避免干扰原始数据逻辑
– payload 用jsonb_build_object()构造，别拼字符串
示例（带容错）：
CREATE OR REPLACE FUNCTION sync_to_api() RETURNS TRIGGER AS $$
BEGIN
PERFORM http_post(
'https://svc.example.com/webhook',
jsonb_build_object('op', TG_OP, 'table', TG_TABLE_NAME, 'data', row_to_json(NEW)::jsonb),
'application/json'
);
RETURN NEW;
EXCEPTION
WHEN OTHERS THEN
-- 记录错误但不中断事务
RAISE WARNING 'HTTP sync failed for %: %', TG_TABLE_NAME, SQLERRM;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
dblink_exec 跨库写入必须注意连接状态
dblink_exec 不像 dblink_connect 那样自动管理连接生命周期。你在触发器里反复调用它，若连接断开或未显式关闭，会快速耗尽连接数或卡住事务。
- 常见错误现象：
ERROR: connection not available、ERROR: dblink_send_query called on non-idle connection - 参数差异：
– 第一个参数是连接名（如'remote_conn'），不是连接串
– 连接名需提前用dblink_connect()建立，且**不能在函数内重复 connect**（否则并发下冲突）
– 推荐改用postgres_fdw+ 外部表，更稳定 - 性能影响：每次调用都走一次 TCP 往返，高并发 INSERT 下延迟明显上升
安全写法（复用预建连接）：
-- 提前一次性建立连接（在数据库启动后执行一次）
SELECT dblink_connect('remote_conn', 'host=192.168.1.100 dbname=target_db user=sync_user password=xxx');
<p>-- 触发器函数中只执行
CREATE OR REPLACE FUNCTION sync_to_remote() RETURNS TRIGGER AS $$
BEGIN
PERFORM dblink_exec('remote_conn',
format('INSERT INTO remote_table(id, name) VALUES (%L, %L)', NEW.id, NEW.name)
);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;为什么别在触发器里直接跑 shell_exec 或调用本地程序
PostgreSQL 默认禁用所有外部命令执行（如 system()、exec()），除非你手动编译启用了 plsh 或 plpythonu，并把数据库用户提权到操作系统级——这等于给黑客开了后门。
- 容易踩的坑：
–plpythonu是不受信任的语言，启用后任意数据库用户都能执行任意系统命令
– 即使限制了权限，子进程的环境变量、工作目录、信号处理都不可控
– 日志难追踪，失败时只报ERROR: spi_exec failed这类模糊信息 - 替代思路：
– 改用NOTIFY发消息，由外部监听程序（如 Python 脚本）消费后调用本地命令
– 或用pg_cron定期拉取变更日志表，解耦执行时机
最易被忽略的一点：所有跨库/跨网调用都依赖事务隔离级别。如果你在 READ COMMITTED 下触发，而远程写入慢于本地事务提交，可能造成“已通知但未真正写入”的幻觉；若用 SERIALIZABLE，又可能因远程操作引入序列化失败。这事没银弹，得按你的数据一致性等级来选路。
