在过去的一年里，开发人员在我们的 postgres 9.6 数据库中遇到了序列问题，他们停止工作，因此他们采取了诸如根据最后插入的记录的 pid 手动创建的 pid 插入行，并使用以下代码重置序列的方法：
SELECT pg_catalog.setval(pg_get_serial_sequence('mytable', 'pid'),
(SELECT MAX(pid)+1 FROM mytable) );
我有足够的经验，知道我们应该能够依靠数据库来创建我们的 id，并且基于最后一个最大值创建自己的 PID 不是“最佳实践”，也不是对所有场景都安全，尽管它通常适用于我们的日常使用。
他们第一次停止工作的原因是众所周知的原因，例如表被恢复。但是，此时我认为手动代码和序列是相互踩踏的，序列重置代码并不可靠。很明显，插入最后一个最大值会破坏序列，它只会增加自己的数字。
当我在阅读时，我想知道今天是否有人指出我正确的方向以恢复序列并在现有表上完美工作 - 即使代码到位，有时也会插入来自代码的 pid，基于最后一个最大值。（当然，从长远来看，我完全意识到最好删除所有此类代码 - 但现在有没有办法解决该代码？）
包含在解决方案中的将是 postgreSQL 9.6 中的一种方法，如果发生冲突，它可以自行重置序列 - 不确定是否可能，并准备接受更有经验的人的讲座 - 但这就是我在这里的原因！
最后——这是让我来到这里的一个令人不安的事实——在 pg admin 中重置序列后，我在 pg admin 3 和 4 的表中看到两个 pid，它们也显示在创建脚本中。在 psql 中执行 \d 时不显示“第二个”PID 列，这很好 - 但我认为它可能是相关的。
更新 - 在最后一点上，导致 pg admin 中表的幽灵重复 PID 是因为同一列/表组合有两个序列，第二个是在某个时间创建的，以尝试修复损坏的序列（例如 mytable_pid_seq 和mytable_pid_seq1)。不知道为什么/如何允许在数据库中发生这种情况。