我继承了一个充满数据的现有Postgres数据库。大多数数据都有'created_date'列值。在跟踪之前插入了一些早期数据。
是否有一个Postgres元数据表隐藏在跟踪INSERT查询完成时的某个地方？
答案 0 :(得分：15)
您可以在postgresql.conf中启用track_commit_timestamp（并重新启动）以开始跟踪提交时间戳。然后，您可以获得xmin的时间戳。相关回答：
除非你自己录制，否则PostgreSQL中没有这样的元数据。
您可以从row headers (HeapTupleHeaderData)中推断出部分信息，特别是来自插入交易ID xmin 。它包含插入行的事务的ID（需要决定PostgreSQL的MVCC模型中的可见性）。尝试（对于任何表格）：
SELECT xmin, * FROM tbl LIMIT 10;
有一些限制：
xmin中的数字顺序不明确。但对于大多数数据库，您应该能够推导出：
没有时间戳。
答案 1 :(得分：2)
基于Erwin Brandstetter的答案，如果您使用的是PostgreSQL 9.5或更高版本，则即使track_commit_timestamp已关闭，提交的时间戳记始终记录在预写日志中。 。它们被记录在此处以支持时间点恢复，您可以在其中将数据库滚动到可以指定为日期和时间的确切过去状态。
打开track_commit_timestamp可以得到一种更容易的信息检索方式，您可以在其中轻松查询
SELECT pg_xact_commit_timestamp(xid);
其中 xid 是您关心的行中的xmin，它为您提供了时间戳。
这很方便，但仅在以下情况下有效：
track_commit_timestamp已打开（PostgreSQL通过最终“冻结”旧的ID来控制永远记住事务ID的开销。这还控制了依赖于track_commit_timestamp的函数可以回溯多远。还有另一种设置，vacuum_freeze_max_age ，以进行调整。）
那么如果您需要在打开track_commit_timestamp之前发生的事务的时间戳怎么办？
只要在PG 9.5或更高版本中发生，时间戳记就在预写日志中。如果您一直保持备份足以进行时间点恢复，那么这为您提供了一种简单的解决方案：您可以在认为基本备份发生之前就对其进行恢复，并在附近位置设置恢复“暂停”目标时间戳记猜测是否发生了，暂停时连接并查询是否发生了。如果不是，请设置稍后的目标，让恢复继续，然后再次检查。可以使用另一个PostgreSQL实例中的备份来完成所有操作，以避免干扰一个正在运行的生产。
这是一个笨拙的过程，您可能希望自己回到过去，告诉以前的自己打开track_commit_timestamp，所以在您感兴趣的交易发生时就已经打开了。您可以 在启动服务器从备份中恢复之前打开track_commit_timestamp，但这并不能解决问题：如果在备份时将其关闭，它将在交易恢复后，才开始为新交易保存时间戳。
事实证明，有可能使PostgreSQL误以为track_commit_timestamp ，然后启动服务器进行恢复，这具有很多预期的效果：因为它可以从中重放事务预写日志，它确实会记住它们的时间戳，然后您可以使用pg_xact_commit_timestamp()来查询它们。它不会为基本备份中的任何内容提供时间戳，而仅为基本备份之后并从WAL中重放的事务提供时间戳。不过，通过选择已知早于所需事务的基本备份，可以恢复时间戳。
尚无通过这种方式“追溯”设置track_commit_timestamp的官方工具/选项，但是on pgsql-hackers中已经讨论了（可靠且不受支持的）概念验证。
答案 2 :(得分：1)
track_commit_timestamp（boolean）
主要在复制服务器设置时使用。 记录事务的提交时间。此参数只能在
postgresql.conf文件或服务器命令行中设置。默认值为关闭。
答案 3 :(得分：0)
简答：不。
如果有的话，每个人都会抱怨在他们不想跟踪的所有牌桌上浪费空间。