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


Reply via email to