PostgreSQL 9.3插入数据报唯一约束重复错误但无对应记录求助

你遇到的这个情况确实有点费解——明明查不到对应记录，插入却触发唯一键冲突，还只在PostgreSQL 9.3版本出现。结合你的环境（同时安装9.3和10版本，刚完成数据库迁移），我整理几个实用的排查和解决方向：

1. 先确认你真的连接到了目标数据库和Schema #

同时运行两个PostgreSQL版本时，很容易不小心连错实例或数据库。先执行这两条命令验证：

-- 查看当前连接的数据库名称
SELECT current_database();
-- 查看当前的搜索路径（确认是否包含public schema）
SHOW search_path;

另外，查询时最好明确指定Schema，避免因搜索路径配置问题查错表：

SELECT value FROM public.system_configuration_parameter WHERE name = 'serverPerformanceMode';

2. 检查唯一约束的实际定义 #

有时候唯一约束可能不是你直观理解的那样——比如是不是基于lower(name)这类函数的索引约束？如果是这样，数据库里若存在ServerPerformanceMode（首字母大写）的记录，你用小写查询会找不到，但插入小写的serverPerformanceMode就会触发冲突。可以用这条语句查看约束的具体定义：

SELECT conname, pg_get_constraintdef(oid) 
FROM pg_constraint 
WHERE conname = 'system_configuration_parameter_name_key';

如果结果里出现lower(name)之类的函数，那就是大小写敏感导致的问题。

3. 排查未提交事务或锁的问题 #

如果有一个未提交的事务已经插入了serverPerformanceMode记录，其他事务查询不到，但插入会触发冲突。可以查看当前数据库的活跃事务和锁情况：

-- 查看活跃事务的查询内容和状态
SELECT pid, query, state 
FROM pg_stat_activity 
WHERE datname = current_database();

-- 查看目标表的锁占用情况
SELECT * 
FROM pg_locks 
WHERE relation = 'system_configuration_parameter'::regclass;

如果发现长时间未提交的事务，要么等待它提交/回滚，要么谨慎手动终止（注意业务风险）。

4. 验证数据库迁移后的一致性 #

迁移到10没问题但9.3出问题，可能是迁移过程中9.3的数据库出现了数据或约束不一致。你可以对比两个版本的表结构：

• 在9.3中执行\d public.system_configuration_parameter，查看约束细节
• 和PostgreSQL 10中的表结构对比，确认唯一约束的定义完全一致
  也可以尝试在9.3中重建唯一约束：

-- 先删除原有约束
ALTER TABLE public.system_configuration_parameter DROP CONSTRAINT system_configuration_parameter_name_key;
-- 重新添加唯一约束
ALTER TABLE public.system_configuration_parameter ADD CONSTRAINT system_configuration_parameter_name_key UNIQUE (name);

5. 检查是否有触发器/规则干扰 #

有没有可能表上的触发器或规则在插入时偷偷创建了重复记录？可以查询表上的触发器配置：

SELECT tgname, pg_get_triggerdef(t.oid) 
FROM pg_trigger t 
JOIN pg_class c ON t.tgrelid = c.oid 
WHERE c.relname = 'system_configuration_parameter';

如果存在异常的触发器（比如自动复制数据或修改插入值的），可能会导致冲突。

内容的提问来源于stack exchange，提问作者Shubham Chand