Re: [HACKERS] upgrading to 6.4 from 6.3
От | Bruce Momjian |
---|---|
Тема | Re: [HACKERS] upgrading to 6.4 from 6.3 |
Дата | |
Msg-id | 199808310441.AAA07672@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] upgrading to 6.4 from 6.3 (Vadim Mikheev <vadim@krs.ru>) |
Список | pgsql-hackers |
> Bruce Momjian wrote: > > > > Here is the last thing I think I promised for 6.4. It is a script that > > will allow 6.3.* users to upgrade to 6.4 without reloading all their > > data. > > > > It works by copying the user tables/index files to a backup directory, > > destroying and recreating the database, then using the > > pg_dump/pg_dumpall output to re-create the tables and indexes, without > > the COPY commands. It then moves the table/index files back into the > > directory. > > But how about pg_log & pg_variable ? > Shouldn't nextOid, nextXid and transaction commit/abort infos > be restored ? OK, I have added an 'mv' of pg_log and pg_variable from the old instance. The only problem I see is that the postmaster is running during the script, so shared memory is enabled. If I copy them during that time, do they get preseved, or does the next backend overwrite pg_variable? I wonder if I have to stop the postmaster before I do this, and tell the user to restart it. The new pid lock file would help in this case. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)
В списке pgsql-hackers по дате отправления: