我继承了一个现有的充满数据的 Postgres 数据库。大多数数据都有一个“created_date”列值。一些较早的数据是在跟踪之前插入的。
是否有一个 Postgres 元数据表隐藏在某个地方,用于跟踪INSERT
查询何时完成?
我继承了一个现有的充满数据的 Postgres 数据库。大多数数据都有一个“created_date”列值。一些较早的数据是在跟踪之前插入的。
是否有一个 Postgres 元数据表隐藏在某个地方,用于跟踪INSERT
查询何时完成?
您可以启用track_commit_timestamp
(postgresql.conf
并重新启动)以开始跟踪提交时间戳。然后,您可以为您的xmin
. 相关答案:
PostgreSQL 中没有这样的元数据,除非你自己记录。
您可能能够从行标题 (HeapTupleHeaderData)中推断出一些信息,尤其是从插入事务 id中。它保存插入行的事务的 ID(需要确定 PostgreSQL 的MVCC模型中的可见性)。尝试(对于任何表):xmin
SELECT xmin, * FROM tbl LIMIT 10;
一些限制适用:
xmin
是不明确的。但是对于大多数数据库,您应该能够得出:
不过没有时间戳。
基于 Erwin Brandstetter 的回答,如果您有 PostgreSQL 9.5 或更高版本,则提交的时间戳将一直记录在预写日志中,即使track_commit_timestamp
已关闭。它们被记录在那里以支持时间点恢复,您可以在其中将数据库滚动到您可以指定为日期和时间的确切过去状态。
通过打开您获得的track_commit_timestamp
是一种更简单的方法来检索该信息,您可以在其中简单地查询
SELECT pg_xact_commit_timestamp(xid);
其中xid是xmin
您关心的行中的第一个,它为您提供时间戳。
这很方便,但仅在以下情况下才有效:
track_commit_timestamp
开启(PostgreSQL 通过最终“冻结”旧的来控制永久记住事务 ID 的开销。这也控制了track_commit_timestamp
-dependent 函数可以回溯的距离。还有另一个设置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
以这种方式“追溯”设置的官方工具/选项,但是(繁琐且不受支持的)概念证明已在pgsql-hackers
.
track_commit_timestamp(布尔值)
主要在复制服务器设置时使用。记录事务的提交时间。此参数只能在
postgresql.conf
文件中或服务器命令行中设置。默认值为off。
简短的回答:没有。
如果有,每个人都会抱怨在他们不想跟踪的所有表上浪费空间。