Re: Strange problem when upgrading to 7.2 with pg_upgrade.
От | Bruce Momjian |
---|---|
Тема | Re: Strange problem when upgrading to 7.2 with pg_upgrade. |
Дата | |
Msg-id | 200202220512.g1M5Ctf21477@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: Strange problem when upgrading to 7.2 with pg_upgrade. (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Strange problem when upgrading to 7.2 with pg_upgrade.
|
Список | pgsql-hackers |
Tom Lane wrote: > Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> I suspect that pg_upgrade has neglected to make sure the clog is long > >> enough. > > > Here is the code that sets the transaction id. Tom, does pg_resetxlog > > handle pg_clog file creation properly? > > pg_resetxlog doesn't know a single solitary thing about the clog. > > The problem here is that if you're going to move the current xact ID > forward, you need to be prepared to create pages of the clog > accordingly. Or maybe the clog routines need to be less rigid in their > assumptions, but I'm uncomfortable with relaxing their expectations > unless it can be shown that they may fail to cope with cases that > arise in normal system operation. This isn't such a case. We increased the xid because the old files have xid's that are greater than the newly initdb'ed database. We did a vacuum, so no one is going to check clog, but we need to increase the transaction counter because old rows could be seen as matching the current transaction. Can you suggest how to create the needed clog files? I don't see any value in changing your current clog code in the backend. -- Bruce Momjian | http://candle.pha.pa.us pgman@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 по дате отправления: