| From: | Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | vadim(at)krs(dot)ru (Vadim Mikheev) |
| Cc: | hackers(at)postgreSQL(dot)org |
| Subject: | Re: [HACKERS] upgrading to 6.4 from 6.3 |
| Date: | 1998-08-31 04:41:16 |
| Message-ID: | 199808310441.AAA07672@candle.pha.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(at)candle(dot)pha(dot)pa(dot)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)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 1998-08-31 04:50:00 | Re: [HACKERS] Core dump in regression tests. |
| Previous Message | Bruce Momjian | 1998-08-31 04:39:23 | Re: Possible bug from 6.3.2t |