PostgreSQL复合主键冲突疑问：时间戳值不同却触发重复键错误

这个问题看起来有点反直觉——明明两个时间戳的微秒部分不一样，却触发了复合主键的重复约束冲突，核心原因大概率是时间戳在存储或传输过程中丢失了精度，导致PostgreSQL接收到的两个时间戳实际是同一个值。下面是具体的排查方向和解决办法：

1. 检查表字段的实际存储精度 #

你手动定义的表结构里registered是timestamp without timezone（PostgreSQL默认是微秒级精度，6位小数），但实际测试环境中的表可能被修改过，比如通过SQLAlchemy模型定义时指定了更低的精度。

你可以登录PostgreSQL终端，执行以下命令查看表的实际结构：

\d test_table

如果registered字段的类型显示为timestamp without timezone(0)（秒级）或timestamp without timezone(3)（毫秒级），那问题就找到了：插入时微秒部分会被截断，导致两个不同的Python datetime对象被存储成同一个时间戳，进而触发复合主键冲突。

解决办法 #

• 如果是SQLAlchemy模型导致的精度限制，修改模型中registered字段的定义，去掉precision参数（或设置为6）：

  from sqlalchemy import Column, Integer, DateTime
  
  class TestTable(Base):
      __tablename__ = 'test_table'
      id = Column(Integer, primary_key=True)
      # 去掉precision参数，使用默认的微秒级精度
      registered = Column(DateTime(timezone=False), primary_key=True)
  

• 重新创建表（或修改字段精度）：

  ALTER TABLE test_table ALTER COLUMN registered TYPE timestamp without timezone;
  

2. 排查SQLAlchemy的时间参数绑定逻辑 #

另一种可能是，在插入数据时，Python的datetime对象被错误地格式化为截断了微秒的字符串，导致PostgreSQL接收到的时间戳没有微秒信息。比如：

• 手动用strftime('%Y-%m-%d %H:%M:%S')格式化时间，丢失了微秒部分
• 使用了第三方库或自定义函数处理时间时，意外截断了微秒

解决办法 #

• 直接传递Python的datetime对象给SQLAlchemy，不要手动格式化字符串：

  # 正确方式：直接传入datetime对象
  new_record = TestTable(id=5, registered=datetime.datetime(2018, 4, 20, 14, 56, 15, 757907))
  session.add(new_record)
  session.commit()
  

• 检查代码中是否有修改datetime对象的逻辑，比如调用了replace(microsecond=0)等截断微秒的方法。

3. 验证时区转换导致的隐式精度丢失 #

虽然你用的是timestamp without timezone，但如果你的Python datetime对象是带时区的（tz-aware），插入时PostgreSQL会将其转换为数据库时区的时间，若转换过程中出现精度丢失（极端情况），也可能导致冲突。

解决办法 #

• 确保插入的datetime对象是无时区的（tz-naive），或者统一转换为UTC时间后再插入：

  # 转换为无时区的datetime
  naive_dt = aware_dt.replace(tzinfo=None)
  

4. 确认数据库中的实际记录 #

最后，直接查询数据库中的记录，验证存储的时间戳是否和你认为的一致：

SELECT id, registered FROM test_table WHERE id = 5;

如果查询结果显示的时间戳和你代码中插入的757907微秒版本一致，那说明之前的记录查询有误（比如单元测试中的数据查询逻辑有问题）。

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