Re: Lifetime of commit timestamps

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Lifetime of commit timestamps
Дата
Msg-id 20231117212046.rd5vwbieaawdrzu3@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Lifetime of commit timestamps  ("Euler Taveira" <euler@eulerto.com>)
Ответы Re: Lifetime of commit timestamps
Список 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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: should check collations when creating partitioned index
Следующее
От: Andres Freund
Дата:
Сообщение: Re: simplehash: preserve consistency in case of OOM