Skip site navigation (1) Skip section navigation (2)

Re: Proposal: vacuum and autovacuum parameters to control freezing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
Subject: Re: Proposal: vacuum and autovacuum parameters to control freezing
Date: 2006-11-05 16:26:20
Message-ID: 14181.1162743980@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
"Simon Riggs" <simon(at)2ndquadrant(dot)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 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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2006-11-05 16:29:06
Subject: Re: Proposal: vacuum and autovacuum parameters to control freezing
Previous:From: Tom LaneDate: 2006-11-05 16:10:13
Subject: Re: [HACKERS] Bug in WAL backup documentation

pgsql-patches by date

Next:From: Tom LaneDate: 2006-11-05 16:29:06
Subject: Re: Proposal: vacuum and autovacuum parameters to control freezing
Previous:From: Tom LaneDate: 2006-11-05 16:10:13
Subject: Re: [HACKERS] Bug in WAL backup documentation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group