Re: [HACKERS] PG_UPGRADE status
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] PG_UPGRADE status |
Дата | |
Msg-id | 199909082240.SAA27668@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] PG_UPGRADE status? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] PG_UPGRADE status
|
Список | pgsql-hackers |
> The issue with MVCC is that the state of a tuple isn't solely determined > by what is in the disk file for its table; you have to also consult > pg_log to see whether recent transactions have been committed or not. > 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. > > OTOH, it seems to me that this was true in older releases as well > (pg_log has always been critical data), so I guess I'm not clear on > why pg_upgrade worked at all, ever... At the end of pg_upgrade, there are the lines: mv -f $OLDDIR/pg_log datamv -f $OLDDIR/pg_variable dataecho "You may remove the $OLDDIR directory with 'rm -r $OLDDIR'."exit0 This is used to get the proper transaction status into the new installation. Is the VACUUM added to pg_upgrade necessary? -- 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
В списке pgsql-hackers по дате отправления: