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...
regards, tom lane
