Re: Proposal: vacuum and autovacuum parameters to control freezing

"Simon Riggs" <simon@2ndquadrant.com> writes:
> now we have agreed to have only 4 eras, IIRC:

> 1. In Progress Transactions            0 - OldestXmin
>     <---- limit is OldestXmin
> 2. Completed, normal Xids, status in clog
>     <---- limit is Freeze distance?
> 3. Frozen Xids, tuples frozen early to ensure nothing passes Wrap
>     <---- critical age? - practical last point to forestall Wrap
>     <---- limit is Wraparound
> 4. Frozen Xids (PreHistory)

You've got the eras right but not the boundaries.  The limit on era 2 is
the current system-wide minimum relfrozenxid (or equivalently, the
current system-wide minimum datfrozenxid), which is where we have
truncated clog.  That will normally be a little more than
autovacuum_freeze_limit --- the difference corresponding to the
"reaction time" needed to fire up autovac and get through all the tables
that have exceeded autovacuum_freeze_limit.  The freeze_distance has to
be considerably *less* than this, else we'll constantly be firing new
autovac cycles each of which will freeze just a few more tuples.

> Perhaps you could edit the above if needed?

1. In Progress Transactions            0 - OldestXmin<---- limit is OldestXmin
2. Completed, normal Xids, status in clog<---- limit is length of clog (a bit more than freeze_limit)       <---- Xids
olderthan freeze_distance will be frozen whenever             next visited by VACUUM, but there is no forcing function
          until they exceed freeze_limit
 
3. Frozen Xids, tuples frozen early to ensure nothing passes Wrap<---- limit is Wraparound
4. Frozen Xids (PreHistory)

We also have that the time between forced autovacuums of unchanging
tuples is approximately freeze_limit - freeze_distance.

> AFICS freeze_limit and freeze_distance are both expressed in number of
> Xids before current, so the "units" are the same for both.

Check.  Actually, as coded there's a bit of difference: freeze_distance
is subtracted from OldestXmin whereas freeze_limit is subtracted from
ReadNextTransactionId().  Normally OldestXmin should be so much smaller
than these parameters that it won't matter, but vacuum.c does contain
logic to do something reasonable if not.

> In that case,
> maybe slightly more differentiated names would be appropriate.

Got a suggestion?  I think the names *should* be clearly related, but
as I said, I'm by no means wedded to these particular ones.
        regards, tom lane