"Simon Riggs" <[EMAIL PROTECTED]> writes:
> vacuum_freeze_min The latest TransactionId that will be "frozen" during
> a VACUUM is calculated by CurrentTransactionId - vacuum_freeze_min.
>
> vacuum_freeze_max
> The maximum age, calculated as distance from CurrentTransactionId, that
> will be al
"Simon Riggs" <[EMAIL PROTECTED]> writes:
> On Sun, 2006-11-05 at 12:01 -0500, Tom Lane wrote:
>> After re-reading the above, it strikes me that maybe names based around
>> "freeze_min" and "freeze_max" would be useful?
> Works for me. They are clearly related, yet different and allow a
> straight
On Sun, 2006-11-05 at 12:01 -0500, Tom Lane wrote:
> After re-reading the above, it strikes me that maybe names based around
> "freeze_min" and "freeze_max" would be useful?
Works for me. They are clearly related, yet different and allow a
straightforward explanation of their need and use.
e.g.
I wrote:
> "Simon Riggs" <[EMAIL PROTECTED]> writes:
>> Perhaps you could edit the above if needed?
> < Xids older than freeze_distance will be frozen whenever
> next visited by VACUUM, but there is no forcing function
> until they exceed freeze_limit
>> In
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes:
> I think a global critical_age parameter is just fine. If you have one
> huge table that takes a long time to vacuum, just adjust critical_age so
> that there's enough time for the huge table vacuum to finish before
> wrap-around. That means that
"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 fr
Tom Lane wrote:
* It might seem that there's no point in per-table adjustment of
critical_age, since only the system-wide maximum means anything for
resource consumption. I'm not so sure though --- for a really large
table, the time needed to finish vacuuming it could be significant,
meaning it
On Sat, 2006-11-04 at 12:35 -0500, Tom Lane wrote:
> I wrote:
> > It's usually going to be the case that the oldest datvacuumxid is
> > template0's, meaning that it will never be possible to truncate clog
> > until autovacuum decides that template0 is at risk of wraparound and
> > goes and vacuums
