当我们更改计算机日期/时间时，postgresql 的 uuid_generate_v1() 可能会发生冲突吗？

Question

根据postgresql uuid-ossp文档uuid_generate_v1()是基于Mac地址+时间戳：

在分布式数据库场景中，我们有数百个数据库使用 UUID 键生成记录并同步回中央数据库。

假设我们检测到一台机器将来的日期/时间错误，我们将其改回正确的日期/时间。它可能会在此特定计算机上生成冲突的 UUID 密钥吗？

一种情况是夏令时/夏令时。

Answer 1

据我所知，没有理由使用uuid_generate_v1()over uuid_generate_v4()。也就是说，Phil\xe1\xb5\x80\xe1\xb4\xb9 当他说时基本上是正确的

\n

\n
“一种情况是夏令时/夏令时。” - 不它不是。所有内容均应存储为 UTC。时间总是在前进。\xe2\x80\x93 菲尔\xe1\xb5\x80\xe1\xb4\xb9
\n

\n

即使您的显示时间设置为 DST（或类似 CSTCDT），底层存储机制也应该是 UTC。

\n

也就是说，虽然所有内容都应存储为 UTC，但情况并非总是如此。也有例外，例如 XP 或 Windows 7，您可能会看到某种异常，特别是如果您允许其他操作系统修改 RTC。

\n

而且，如果你真的想挑剔的话，总是存在闰秒的问题，当某些内核或守护进程会回滚秒时，基本上取决于他们是否支持这一点。Linux-proper 和 OSX 确实如此，Android 却没有在闰秒上进行幽默的 NDT

\n

作为参考，该规范详细介绍了生成 UUID v1 基于时间的 UUID 的过程，4.2 创建基于时间的 UUID 的算法。

\n

为了正确地看待问题，*考虑一个包含 2.3 quintillion Version 4 UUID 的文件，其中包含一个 UUID 冲突的可能性为 50%。假设没有其他数据或开销*，其大小将为 36 艾字节。除此之外并不重要。v4 无疑是更流行、更安全的用例。 (2认同)