On Thu, Apr 7, 2011 at 5:52 PM, Bruce Momjian <br...@momjian.us> wrote: > 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.
This depends on how soon after the upgrade VACUUM FREEZE is run, doesn't it? If the XID counter has advanced too far... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
