所以我对 PostgreSQL 计时函数有这个有趣的问题。
情况是这样的。我们有一个预生产服务器 (Linux)，用于存放我们正在开发的应用程序。我还在该数据库 (Windows) 的本地副本上做一些工作，以防服务器正在进行一些更重要的工作。我最近遇到了一个问题，我开始在本地数据库副本的日志表上发现主键违规。我认为这是不可能的，因为我使用 CLOCK_TIMESTAMP(当前系统时间)作为主键。此外，我在预生产服务器上进行了测试，它运行良好。所以我做了一些调查。我最终发现，如果我在服务器上运行“SELECT CLOCK_TIMESTAMP()”，它会将时间返回到微秒。如果我在我的本地主机上运行它，它只会下降到毫秒。因此，当计时器到达下一毫秒之前发生多个更新时，就会出现问题，考虑到我们的某些流程，这绝对是可能的。
所以我的问题是这样的。为什么会发生这种情况，我该如何解决？这是我还没有找到的一些晦涩的设置吗？还是 Windows 与 Linux 的定时器分辨率不同？
编辑:CURRENT_TIMESTAMP、NOW() 和所有其他返回时间戳的内置函数也会发生同样的事情。
谢谢
最佳答案
在这个 pg_hackers 线程上引用 Tom Lane:
http://www.postgresql.org/message-id/9699.1262011789@sss.pgh.pa.us
I suppose what you're really asking about is not the precision of the datatype but the precision of now() readings. You're out of luck --- Windows just doesn't expose a call to get the wall clock time to better than 1 msec.
Keep in mind that whatever the Linux machine is returning might be largely fantasy in the low-order bits, too.
要解决您的问题，请考虑使用序列号作为主键。 (当然，假设您实际上首先需要日志文件的主键。)
关于linux - PostgreSQL:CURRENT_TIMESTAMP 和 CLOCK_TIMESTAMP 解决方案:Windows 与 Linux？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19776593/