我的工作表上有这个案例。
客户已重启（至少2次）运行PostgreSQL的计算机。之后，一列上的序列的nextval已经改变。
重启前的最后一个值是582.重启后它应该返回583，但它返回615。
我检查了所有可能的日志，从linux系统日志到PostgreSQL日志，直到我们的应用程序日志，没有看到任何调用此行的nextval。
所以我尝试了疯狂的想法，并将数字翻译成了一些......
583 in bits: 0010 0100 0111
615 in bits: 0010 0110 0111
只有一点差异。那么，是否有可能从硬重启中弄乱了一位???
在这段时间内，这个下一次被召唤33次的确如此没有多少选择。返回582的呼叫和返回615的呼叫之间的时间差仅相当于小时左右，并且在那个时间内PC重启了两次。是的，编程需要很长时间，但在此期间没有看到nextval。
编辑＃1：
我检查了cache_value，它是1（因为它应该是）。 increment_by也是1。所以不应该有任何分配的值。调用nextval的代码连接到硬件开关（Cashbox传感器），激活后，它会找到Cashbox状态并将其插入到id为此序列的表中。在插入新行之前有一些相当重的选择，所以如果它被调用，我们的应用程序日志或PostgreSQL日志中会有一些足迹。
我之所以关心的是，这个序列用于钱箱更改日志上的ID，所以ID中的差距看起来并不好，即使我们可以证明这两个ID之间没有任何关系
答案 0 :(得分：3)
请参阅this Postgres documentation for details on how sequences are generated in Postgres。
引用文档：
因此，在会话中分配但未使用的任何号码都将丢失 当该会话结束时，序列中会出现“漏洞”。
正在发生的事情可能是序列生成器有一些缓存的序列值，这些值在硬重启期间会丢失。或者，正在进行的一个或多个事务已检索到序列值，但在它们能够提交事务之前被中断。
documentation on sequence generation可以帮助您确定如何设置序列缓存的大小，以及“重新启动”的值。
此外： 在您的情况下，听起来好像您可能有一个业务规则要求表中的主键既顺序又无间隙（序列之间没有间隙）。 A. Elein Mustain提出了一个非平凡的solution to generating so called "gapless sequences"。