Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] upgrading to 6.4 from 6.3

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: (view raw, whole thread or download thread mbox)
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

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)

In response to

pgsql-hackers by date

Next:From: Bruce MomjianDate: 1998-08-31 04:50:00
Subject: Re: [HACKERS] Core dump in regression tests.
Previous:From: Bruce MomjianDate: 1998-08-31 04:39:23
Subject: Re: Possible bug from 6.3.2t

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group