我的工作桌上有这个案子.
客户已重新启动(至少2次)运行Postgresql的计算机.此后,一个列上的序列的下一个值已更改.
重新启动之前的最后一个值是582.重新启动之后,它应该返回583,但是返回615.
我已经检查了所有可能的日志,从linux系统日志到Postgresql日志,直到我们的应用程序日志,看不到在此行调用nextval的任何内容.
所以我尝试了这个疯狂的主意,然后将数字转换为位.
583 in bits: 0010 0100 0111
615 in bits: 0010 0110 0111
只有一点点差异.因此,是否可能从硬重启中惹来麻烦？？？
确实没有太多选择,那么下次将nextval称为33次.返回582的呼叫和返回615的呼叫之间的时间差仅约一个小时,而此时PC两次重新启动.是的,编程时间很长,但是在这段时间内没有看到调用nextval的迹象.
编辑#1：
我已经检查过cache_value,它是1(可能应该是).同样,increment_by也为1.因此,不应有任何分配的值.调用nextval的代码已连接到硬件开关(钱箱传感器),当被激活时,它将找出钱箱状态并将其插入ID为该序列的表中.在插入新行之前,需要进行一些繁重的选择,因此,如果调用了它,则我们的应用程序日志或Postgresql日志中都会有一些占用空间.
我关心的原因是,此序列用于钱箱更改日志上的ID,因此ID的间隔看起来不太好,即使我们可以证明这2个ID之间没有做任何事情.
解决方法:
请参考this Postgres documentation for details on how sequences are generated in Postgres.
引用文档：
So, any numbers allocated but not used within a session will be lost
when that session ends, resulting in “holes” in the sequence.
可能发生的情况是,任一序列生成器都有一些缓存的序列值,这些值在硬重启期间会丢失.或者,一个或多个进行中的事务已检索到序列值,但是在它们能够提交事务之前被中断.
documentation on sequence generation可以帮助您确定如何设置序列缓存的大小以及“重新启动”的值.
此外：
在您的情况下,听起来好像您有一条业务规则,要求表中的主键既要连续又要无间隙(序列之间没有间隙). A. Elein Mustain建议一个不平凡的solution to generating so called “gapless sequences”.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
