Re: [HACKERS] PG_UPGRADE status

> Bruce Momjian <maillist@candle.pha.pa.us> writes:
> >> pg_upgrade doesn't import the old pg_log into the new database (and
> >> can't very easily, since the new database will have its own), so there's
> >> a problem with recent tuples possibly getting lost.
> 
> > At the end of pg_upgrade, there are the lines:
> >     mv -f $OLDDIR/pg_log data
> >     mv -f $OLDDIR/pg_variable data
> > This is used to get the proper transaction status into the new
> > installation.  Is the VACUUM added to pg_upgrade necessary?
> 
> I'm sorry, I had that backwards (knew I shoulda checked the code).
> 
> pg_upgrade *does* overwrite the destination pg_log, and what that
> means is that incoming tuples in user relations should be fine.
> What's at risk is recently-committed tuples in the system relations,
> notably the metadata that pg_upgrade has just inserted for those
> user relations.
> 
> The point of the VACUUM is to try to ensure that everything
> in the system relations is marked as certainly committed (or
> certainly dead) before we discard the pg_log information.
> I don't recall ever hearing from Vadim about whether that
> is a trustworthy way of doing it, however.
> 
> One thing that occurs to me just now is that we probably need
> to vacuum *each* database in the new installation.  The patch
> I added to pg_dump doesn't do the job because it only vacuums
> whichever database was dumped last by pg_dumpall...
> 

I have modified pg_upgrade to vacuum all databases, as you suggested.
copy pg_shadow from stdin;\.
->    VACUUM;\connect template1 postgrescreate database test;\connect test postgres\connect - postgresCREATE TABLE "t1"
(

I left your vacuum in there to vacuum the last database.  This should
help.

--  Bruce Momjian                        |  http://www.op.net/~candle maillist@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026