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

From Bruce Momjian
Subject Re: Lifetime of commit timestamps
Date
Msg-id ZVfc7Bm6r-TjdZfg@momjian.us
Whole thread Raw
In response to Re: Lifetime of commit timestamps  (Andres Freund <andres@anarazel.de>)
Responses Re: Lifetime of commit timestamps
List pgsql-hackers
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  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Only you can decide what is important to you.

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Permute underscore separated components of columns before fuzzy matching
Next
From: Jeff Davis
Date:
Subject: Re: Change GUC hashtable to use simplehash?