Re: Lifetime of commit timestamps
От | Bruce Momjian |
---|---|
Тема | Re: Lifetime of commit timestamps |
Дата | |
Msg-id | ZVfc7Bm6r-TjdZfg@momjian.us обсуждение исходный текст |
Ответ на | Re: Lifetime of commit timestamps (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Lifetime of commit timestamps
|
Список | 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.
Вложения
В списке pgsql-hackers по дате отправления: