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: [EMAIL PROTECTED]> CC: [EMAIL PROTECTED]; [email protected]>
> Subject: Re: [ADMIN] Is it safe to reset relfrozenxid without using vacuum?
> > Date: Tue, 18 Nov 2008 13:07:16 -0500> From: [EMAIL PROTECTED]> > Alvaro
> Herrera <[EMAIL PROTECTED]> 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
_________________________________________________________________
