Re: VACUUM FULL/CLUSTER doesn't update pg_class's pg_class.relfrozenxid

On Thu, Feb 27, 2014 at 1:06 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> As Robert previously complained a database wide VACUUM FULL now (as of
> 3cff1879f8d03) reliably increases the relfrozenxid for all tables but
> pg_class itself. That's a bit sad because it means doing a VACUUM FULL
> won't help in a anti-wraparound scenario.
>
> The reason for that is explained by the following comment:
> /*
> * Update the tuples in pg_class --- unless the target relation of the
> * swap is pg_class itself. In that case, there is zero point in making
> * changes because we'd be updating the old data that we're about to throw
> * away. Because the real work being done here for a mapped relation is
> * just to change the relation map settings, it's all right to not update
> * the pg_class rows in this case.
> */
>
> I think the easiest fix for that is to update pg_class' relfrozenxid in
> finish_heap_swap() after the indexes have been rebuilt, that's just a
> couple of lines. There's more complex solutions that'd avoid the need
> for that special case, but I it's sufficient. A patch doing that is
> attached.

So, this patch is obviously after the final CommitFest deadline, but
I'd like to commit it to 9.4 anyway on admittedly-arguable theory that
it's tying up a loose end introduced by
3cff1879f8d03cb729368722ca823a4bf74c0cac. Prior to that commit,
VACUUM FULL and CLUSTER *never* updated relfrozenxid; beginning with
that commit, they do so for all relations except pg_class. This
tidies up that omission.

And I think that's a pretty worthwhile thing to do, because we get
periodic reports from people who have run VACUUM FULL on a database in
danger of wraparound and then wondered why it did not fix the problem.
The previously-mentioned commit did most of the heavy lifting as far
as tidying that up, but without this adjustment it won't quite get us
over the hump.

But all that having been said, a deadline is a deadline, so if anyone
wishes to declare this untimely please speak up.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company