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
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 |