Re: Lifetime of commit timestamps

From: Andres Freund <andres(at)anarazel(dot)de>
To: Euler Taveira <euler(at)eulerto(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Lifetime of commit timestamps
Date: 2023-11-17 21:20:46
Message-ID: 20231117212046.rd5vwbieaawdrzu3@awork3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-11-17 21:22:31 Re: simplehash: preserve consistency in case of OOM
Previous Message Jeff Davis 2023-11-17 21:08:09 Re: should check collations when creating partitioned index