Re: Lifetime of commit timestamps - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Lifetime of commit timestamps
Date
Msg-id 20231117212046.rd5vwbieaawdrzu3@awork3.anarazel.de
Whole thread Raw
In response to Re: Lifetime of commit timestamps  ("Euler Taveira" <euler@eulerto.com>)
Responses Re: Lifetime of commit timestamps
List pgsql-hackers
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).


> The answer is the design used a existing mechanism to clean up data in order
> to avoid creating a new one.

I don't really understand this part - independent of the mechanism (i.e. an
slru), at some point we need to remove old data, just for space reasons.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: should check collations when creating partitioned index
Next
From: Andres Freund
Date:
Subject: Re: simplehash: preserve consistency in case of OOM