2

我不确定如何通过生成UUID值来处理这种奇怪的行为。我知道 uuid_generate_v1() 不如 uuid_generate_v4() 安全。

我们在函数内部执行 uuid_generate_v1() 以生成唯一的 Id。最初创建函数时，它返回填充的 uuid 的所有段。我最近需要创建另一个 Azure PostgreSQL 实例并验证输出，并注意到 uuid 的最后一段现在为零。我重新验证了我们拥有的另一个 Azure PostgreSQL 实例，它们现在也返回尾随零。

uuid_generate_v4() 在所有实例上都可以正常工作。

我在笔记本电脑的 docker 容器中安装了一个 PostgreSQL 9.6 版本，它返回填充的所有段。

uuid_id
9945111c-b305-11e9-aec6-977857a8b0e6
be647cc2-7cbd-11e9-8498-e7d5a16a0cec

fa1ee220-bf8e-11e9-8b75-000000000000

我在想也许执行了更新，但我不确定我会在哪里检查。

希望有人可能遇到过这种情况。

4

1 回答 1

2

缺少 MAC 地址

fa1ee220-bf8e-11e9-8b75-000000000000

该十六进制字符串表示UUID的128 位。最后十二个十六进制字符用于48 位节点 id。对于版本 1 UUID，节点 ID表示生成 UUID 的机器的MAC 地址。

大多数其他十六进制字符表示（a）当前日期和时间值的位，其余几个位表示（b）一个小的任意数字，以及（c）UUID 的变体和版本。这三个数据源很容易获得，所以没有问题，因此您会看到前四个部分已填充。

可能是 Azure 的错误

所以我猜你看到了一个关于Azure 未能报告其托管数据库的虚拟机的 MAC 地址的错误。

您没有看到版本 4 UUID 的问题，因为该版本不使用 MAC 地址。版本 4使用随机生成的位，128 位中的 122 位是随机的。

您没有在笔记本电脑上看到问题，因为您的计算机（或 Docker 容器）正确地将其 MAC 地址报告给生成 UUID 值的 Postgres 插件。

我建议您将您的体验作为错误报告给 Azure 员工。Azure 的人可能不认为这是一个错误。出于您在问题中提到的安全原因，他们可能故意选择不透露其服务器的 MAC 地址。

我怀疑问题出在Postgres、 Postgres 插件uuid-ossp或插件中包含的陈旧的 OSSP uuid库。

解决方法

您可以尝试使用 OSSP 库提供的版本 1 UUID 的特殊变体：uuid_generate_v1mc(). 这使用随机多播 MAC 地址，而不是主机的真实 MAC 地址。

提示：对于测试/调试，您可以简单地执行SELECT uuid_generate_v1() ;. 无需保存到行并检索。

于 2019-08-24T00:56:00.263 回答