Re: [PATCH] Periodically refresh database frozen IDs during autovacuum

Hi,

On 2026-11-03 00:40:15 +0800, Jingtang Zhang wrote:
> This patch periodically refreshes the database's frozen-ID horizons
> between tables. A shared per-database completion timestamp controls
> periodic attempts at a fixed interval, currently set to ten minutes.
> This is a tentative value for discussion, since more frequent updates
> incur additional scanning overhead. I have not yet decided whether to
> make the interval configurable via a GUC.
>
> To prevent multiple workers from refreshing the same database
> concurrently, periodic updates acquire the database frozen-ID lock
> conditionally. If the lock is already held, another backend is handling
> the database-level refresh, so the worker skips its attempt and
> continues processing tables. The existing final blocking refresh is
> retained as a fallback.

I think theres some responsibilities that aren't quite right here (even before
your change). A few comments (both about the current state and the patch):

- Just updating the datfrozenxid at the end of an autovacuum and a
multi-relation vacuum is problematic and makes it more likely that
anti-wraparound measures are hit

I think the same update-more-often logic needs to be done for multi-relation
vacuums.

- Calling vac_update_datfrozenxid() unconditionally in do_autovacuum(), even
though relfrozenxid wasn't updated, is wasteful and makes more frequent
calls problematic

The justification for calling vac_update_datfrozenxid() even if we didn't
vacuum anything doesn't mean we can't push the responsibility for other
calls to vac_update_datfrozenxid() down. If we do, we can make those
updates conditional.

- We shouldn't block waiting for LockDatabaseFrozenIds in most cases, because
that means somebody else is already doing the work.

I suspect we should use something like the ForceTransactionIdLimitUpdate()
check at the end of vac_update_datfrozenxid() to determine whether to block
or not.

That seems like something independent of more frequently updating
datfrozenxid. So it probably should be a separate patch.

- The timing logic the patch introduces makes calls to
vac_update_datfrozenxid() independent of relfrozenxid having been updated,
that

Greetings,

Andres Freund