Robert Haas wrote: > 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...
Well, I assume VACUUM FREEZE is going to sequential scan the table and replace every xid. If the clog is gone, well, we have problems. I think the IRC reporter pulled the clog files from a backup. -- 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
