Jeff Davis wrote:
> On Thu, 2011-04-07 at 12:38 -0700, Jeff Davis wrote:
> > > Any idea how to correct existing systems? Would VACUUM FREEZE of just
> > > the toast tables work?
> >
> > VACUUM FREEZE will never set the relfrozenxid backward. If it was never
> > preserved to begin with, I assume that the existing value could be
> > arbitrarily before or after, so it might not be updated.
>
> Now that I understand the problem a little better, I think VACUUM FREEZE
> might work, after all.
Good. I don't want to be inventing something complex if I can avoid it.
Simple is good, espeically if admins panic. I would rather simple and
longer than short but complex :-)
> Originally, I thought that the toast table's relfrozenxid could be some
> arbitrarily wrong value. But actually, the CREATE TABLE is issued after
> the xid of the new cluster has already been advanced to the xid of the
> old cluster, so it should be a "somewhat reasonable" value.
Yes, it will be reasonable.
> That means that VACUUM FREEZE of the toast table, if there are no
> concurrent transactions, will freeze all of the tuples; and the
> newFrozenXid should always be seen as newer than the existing (and
> wrong) relfrozenxid. Then, it will set relfrozenxid to newFrozenXid and
> everything should be fine. Right?
Right.
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +