Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? ) - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )
Date
Msg-id 1250380541.23986.60.camel@jdavis
Whole thread Raw
In response to Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: freezing tuples ( was: Why is vacuum_freeze_min_age 100m? )  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-hackers
On Sun, 2009-08-16 at 02:02 +0300, Peter Eisentraut wrote:
> For min, the action happens at or above the min values.  For max, the
> action happens at or below the max value.

>From the docs, 23.1.4:

"autovacuum is invoked on any table that might contain XIDs older than
the age specified by the configuration parameter
autovacuum_freeze_max_age"

I interpret that to mean that the forced autovacuum run happens above
the value. You could reasonably call it the "minimum age of relfrozenxid
that will cause autovacuum to forcibly run a vacuum". 

Similarly, you could call vacuum_freeze_min_age "the maximum age a tuple
can be before a vacuum will freeze it".

I'm not trying to be argumentative, I'm just trying to show that it can
be confusing if you interpret it the wrong way. The first time I saw
those configuration names, I was confused, and ever since, I have to
think about it: "is that variable called min or max?".

My general feeling is that both of these are thresholds. The only real
maximum happens near wraparound.

> With those two particular parameters, the freezing happens exactly
> between the min and the max value.

Thanks, that's a helpful way to remember it.

It may be a little obsolete because now the freezing will normally
happen between vacuum_freeze_min_age and vacuum_freeze_table_age; but at
least I should be able to remember which of the other parameters is
"min" and which one is "max".

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Remove tabs from SGML.
Next
From: Andrew Dunstan
Date:
Subject: Re: [COMMITTERS] pgsql: Remove tabs from SGML.