Re: effective_multixact_freeze_max_age issue

From: "Anton A(dot) Melnikov" <a(dot)melnikov(at)postgrespro(dot)ru>
To: Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: Nathan Bossart <nathandbossart(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>
Subject: Re: effective_multixact_freeze_max_age issue
Date: 2024-04-05 06:30:02
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Hi, Peter!

Sorry! For a some time i forgot about this thread and forgot to
thank you for your answer.

Thereby now its clear for me that this patch allows the autovacuum to win some
time between OldestXmin and nextXID that could not be used before.
I think, it maybe especially useful for high-load applications.

Digging depeer, i found some inconsistency between current docs and
the real behavior and would like to bring this to your attention.

Now the doc says that an aggressive vacuum scan will occur for any
table whose multixact-age is greater than autovacuum_multixact_freeze_max_age.
But really vacuum_get_cutoffs() will return true when
multixact-age is greater or equal than autovacuum_multixact_freeze_max_age
if relminmxid is not equal to one.
If relminmxid is equal to one then vacuum_get_cutoffs() return true even
multixact-age is less by one then autovacuum_multixact_freeze_max_age.
For instance, if relminmxid = 1 and multixact_freeze_table_age
= 100,
vacuum will start to be aggressive from the age of 99
(when ReadNextMultiXactId()
= 100).

The patch attached attempts to fix this and tries to use semantic like in the doc.
The similar fix was made for common xacts too.
Additional check for relminxid allows to disable agressive scan
at all if it is invalid. But i'm not sure if such a check is needed here.
Please take it into account.

With kindly regards,

Anton A. Melnikov
Postgres Professional:
The Russian Postgres Company

Attachment Content-Type Size
fix-agressive-vacuum-conds.patch text/x-patch 2.1 KB

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jakub Wartak 2024-04-05 06:59:02 Re: incremental backup breakage in BlockRefTableEntryGetBlocks
Previous Message Hayato Kuroda (Fujitsu) 2024-04-05 06:22:58 RE: Is this a problem in GenericXLogFinish()?