On Fri, 2011-04-08 at 07:08 -0400, Noah Misch wrote:
> > Right, VACUUM FREEZE. I now see I don't need to set
> > vacuum_freeze_table_age if I use the FREEZE keyword, e.g. gram.y has:
> >
> > if (n->options & VACOPT_FREEZE)
> > n->freeze_min_age = n->freeze_table_age = 0;
>
> True; it just performs more work than strictly necessary. We don't actually
> need earlier-than-usual freezing. We need only ensure that the relfrozenxid
> will guide future VACUUMs to do that freezing early enough. However, I'm not
> sure how to do that without directly updating relfrozenxid, so it's probably
> just as well to cause some extra work and stick to the standard interface.
If there are tuples in a toast table containing xids that are older than
the toast table's relfrozenxid, then there are only two options:
1. Make relfrozenxid go backward to the right value. There is currently
no mechanism to do this without compiling C code into the server,
because (a) VACUUM FREEZE will never move the relfrozenxid backward; and
(b) there is no way to find the oldest xid in a table with a normal
snapshot.
2. Get rid of those xids older than relfrozenxid (i.e. VACUUM FREEZE).
I don't know what you mean about VACUUM FREEZE doing extra work. I
suppose you could set the vacuum_freeze_min_age to be exactly the right
value such that it freezes everything before the existing (and wrong)
relfrozenxid, but in practice I think it would be the same amount of
work.
Regards,
Jeff Davis
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
