Re: pg_upgrade bug found!

Bruce Momjian wrote:
> > > 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.

So I think we have four possible approaches to correct databases:

	1) SELECT * to set the hint bits
	2) VACUUM to set the hint bits
	3) VACUUM FREEZE to remove the old xids
	4) some complicated function

I don't like #4, and I think I can script #2 and #3 in psql by using COPY
to create a VACUUM script and then run it with \i.  #1 is easy in a DO
block with PL/pgSQL.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +