upgrading to 6.4 from 6.3
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.
If it works and people like it, I will write up a manual page, and
mention it so people can use it.
I am not sure how to preserve the database owner because I need to
drop/recreate the database. Any ideas?
Vadim, I assume you did not change anything in the table or index
structure. You mentioned an index change, but I do not think you made
it, did you?
--
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)
Attachments:
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 ?
If it works and people like it, I will write up a manual page, and
mention it so people can use it.I am not sure how to preserve the database owner because I need to
drop/recreate the database. Any ideas?Vadim, I assume you did not change anything in the table or index
structure. You mentioned an index change, but I do not think you made
it, did you?
No, I didn't.
Vadim
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)