Robert Haas wrote:
> On Thu, Apr 7, 2011 at 5:52 PM, Bruce Momjian <bruce@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 <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ It's impossible for everything to be true. +