Re: [HACKERS] PG_UPGRADE status
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] PG_UPGRADE status |
Дата | |
Msg-id | 1726.936836853@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] PG_UPGRADE status (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] PG_UPGRADE status
Re: [HACKERS] PG_UPGRADE status |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: