On Fri, Nov 17, 2023 at 01:20:46PM -0800, Andres Freund wrote:
> Hi,
>
> On 2023-11-17 15:39:14 -0300, Euler Taveira wrote:
> > On Mon, Nov 13, 2023, at 9:47 PM, Bruce Momjian wrote:
> > > Is this documentation change still relevant?
> >
> > I think so. AFAICS nothing changed. Unless you read the source code, it is
> > not
> > clear that VACUUM removes the information for frozen tuples. They are
> > decoupled
> > (but executed in the same routine for convenience), hence, someone can ask
> > why
> > the pg_xact_commit_timestamp() returns NULL for a transaction that was
> > executed
> > *after* you enable track_commit_timestamp.
>
> I think the connection between freezing and removal of commit timestamps is a
> lot less direct that your suggested docs suggest. There can be no freezing and
> we'll still remove timestamps (if tuples were deleted/updated). And tuples can
> be frozen without the committs being truncated (if other tables have an older
> relfrozenxid).
>
> The relevant limiting factor is minimum of all databases datfrozenxid. Which
> in turn is limited by relfrozenxid of each table in said database. And
> relfrozenxid is limited by snapshots (and prepared transactions, replication
> slots, etc).
Okay, I went with more weasel-wording in the attached patch.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
Only you can decide what is important to you.
diff --git a/doc/src/sgml/func.sgml b/doc/src/sgml/func.sgml
index 93f068edcf..0f59b9f5f5 100644
--- a/doc/src/sgml/func.sgml
+++ b/doc/src/sgml/func.sgml
@@ -25978,7 +25978,8 @@ SELECT collation for ('foo' COLLATE "de_DE");
They only provide useful data when the
<xref linkend="guc-track-commit-timestamp"/> configuration option is
enabled, and only for transactions that were committed after it was
- enabled.
+ enabled. Commit timestamp information is routinely removed during
+ vacuum.
</para>
<table id="functions-commit-timestamp">
