postgresql - 关于Postgres track_commit_timestamp (pg_xact_commit_timestamp)的问题

Question

我正在设计并发安全的增量聚合汇总系统，track_commit_timestamp (pg_xact_commit_timestamp) 听起来很完美。但是我一般很少找到关于它的评论，也无法从源代码中详细了解它是如何工作的。

希望有人知道我的一个或多个问题的答案:

• 提交时间戳功能是否可能产生乱序的时间？我所追求的是一种识别自特定时间以来已更改的记录的方法，以便我可以获得任何以后的更改以进行处理。如果有相同的时间戳，我不需要它们以完美的提交顺序。

• 最终实现中每一行增加了多少字节？我看到的讨论好像是12-24字节不等。讨论了为“以防万一”添加额外的字节。这是 9.5 之前的版本，已经是过去的世界了。

• 时间戳是否在内部编入索引？用B树？我询问容量规划原因。

• 我在 StackOverflow 和设计讨论中看到时间戳不会无限期保留，但无法找到有关它们确切存储多长时间的详细信息。

• 关于启用 track_commit_timestamp 的性能影响有什么经验法则？我不需要所有表上的数据，但在我需要的地方，听起来它可能工作得很好。

• 有什么陷阱吗？我尝试在测试表上运行 VACUUM FULL 并且 pg_xact_commit_timestamp 都没有改变。看起来像 VACUUM 这样的物理操作不应该改变任何东西，但很容易就会有一些我没有想到的东西。而且，老实说，我的快速 VACUUM 测试甚至可能没有任何意义。

非常感谢您的帮助!

---

我已经编辑了我的问题以阐明我要完成的任务，我希望根据更新标记跟踪已处理和未处理的数据。

select max(pg_xact_commit_timestamp(xmin)) from scan;--   2019-07-07 20:46:14.694288+10

update scan set quantity = 5 where quantity = 1; --       Change some data.

select max(pg_xact_commit_timestamp(xmin)) from scan; --  2019-07-10 09:38:17.920294+10

-- Find the changed row(s):
select * 
  from scan 
 where pg_xact_commit_timestamp(xmin) > '2019-07-07 20:46:14.694288+10'; 

这个想法是对行进行增量和定期汇总。所以，

-- 跟踪最后汇总的时间戳。 -- 等待 5 分钟(或其他时间) -- 查找当前的最大提交时间戳。 -- 搜索提交时间戳介于最后处理的时间戳和最大值之间的行。 -- 将它们卷起来。

单靠事务 ID 是行不通的，因为它们很容易乱序提交。这个时间戳系统不一定要 100% 完美，但我的目标是接近完美。因此，可能会容忍一些时钟摆动，甚至围绕重叠的开始/结束时间出现一些困惑。

这个计划有什么明显的缺陷吗？

Answer 1

由于这个主题似乎很少出现在文件中，我想在继续之前添加一些细节。我在几个列表、论坛和直接交流中询问了相关问题。有几个人很友好地查看了源代码，提供了历史背景，并为我解决了这个问题。希望在这里留下一些细节可以帮助其他人走上正轨。显然，错误都是我的，欢迎更正和改进。

• 提交时间戳是在事务工作完成时分配的，但这与提交时不同。 WAL writer 不会更新时间戳以保持它们按时间顺序排列。

• 因此，提交时间戳绝对不是按顺序查找更改行的可靠机制。

• 多个时钟。自调时钟。哦，人性!

• 如果您确实想要按顺序更改序列，可以选择逻辑解码或复制。 (几周前我通过实验尝试了逻辑复制。最酷的东西。有史以来。)

• 时间戳跟踪的成本是每个事务 12 个字节，而不是每行。所以，还不错。 (时间戳为 8 个字节，事务 ID 为 4 个字节。)

• 这都是现有交易系统的一部分，因此交易 ID 滚动的现实也适用于此。 (对我而言并不可怕。)参见:

  https://www.postgresql.org/docs/current/routine-vacuuming.html

• 作为记录，您可以通过参数组设置在 RDS 上启用此选项。只需将 track_commit_timestamp 设置为 1 并重新启动。 (该设置在 postgres.conf 中为“开启”。)