On a related note...
When I put this change in place, it should handle tables properly going forward and on a new install, but it looks like I have several instances with "clones" of this DB where there are 1000's of tables all with the same relfrozenxid and within just a few million transactions of the autovacuum_freeze_age. So the vast majority of those tables are still going to need to be vacuumed at the same time since the change to the truncation logic won't have been in place long enough to fix the relfrozenxids.
If I "know" that there are no more inserts going into those partitioned tables, can I do a bulk change of their relfrozenxids setting them back 500million transactions without causing problems? This will mean that the relfrozenxid is not representative of the row versions, but does that matter in this case(Essentially static stables)?
> To: alvherre@commandprompt.com
> CC: arctic_toucan@hotmail.com; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] Is it safe to reset relfrozenxid without using vacuum?
> Date: Tue, 18 Nov 2008 13:07:16 -0500
> From: tgl@sss.pgh.pa.us
>
> Alvaro Herrera <alvherre@commandprompt.com> writes:
> > AFAICS this should be safe. In fact, in 8.3 TRUNCATE advances
> > relfrozenxid. (Perhaps you should consider upgrading if possible.)
> > ...
> > Tou could just obtain the xid of the transaction that's going to do the
> > import (for example by creating a temp table and getting it's xmin from
> > pg_class)
>
> That seems a bit risky. 8.3 resets relfrozenxid to RecentXmin, not the
> current transaction's XID. The OP's thought of taking the max existing
> relfrozenxid should be safe though.
>
> Or I guess you could make a temp table and take the relfrozenxid, rather
> than the xmin, from its pg_class entry.
>
> regards, tom lane