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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers