"Simon Riggs" <[EMAIL PROTECTED]> 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 older than 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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
