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 <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
