Reply-To: <gnanam@zoniac.com>
From: "Gnanakumar" <gnanam@zoniac.com>
To: "'Kevin Grittner'" <Kevin.Grittner@wicourts.gov>, <tgl@sss.pgh.pa.us>
Cc: <pgsql-admin@postgresql.org>
References: <4C1092AF0200002500032124@gw.wicourts.gov>
	<004901cb089e$7a366030$6ea32090$@com>
	<4C10A65F020000250003213A@gw.wicourts.gov>
In-Reply-To: <4C10A65F020000250003213A@gw.wicourts.gov>
Subject: Re: Fatal Error during PITR Recovery
Date: Tue, 15 Jun 2010 12:07:26 +0530
Organization: Zoniac Software Private Limited
Message-ID: <011401cb0c55$39cfe330$ad6fa990$@com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Thread-Index: AcsIo1ijgjGVbriCRaSy5afDEJ3c4QDsazEQ
Content-Language: en-us

Hi Kevin,

Thanks for sharing on your way of upgrading.

Regards,
Gnanam

-----Original Message-----
From: Kevin Grittner [mailto:Kevin.Grittner@wicourts.gov] 
Sent: Thursday, June 10, 2010 7:16 PM
To: tgl@sss.pgh.pa.us; gnanam@zoniac.com
Cc: pgsql-admin@postgresql.org
Subject: RE: [ADMIN] Fatal Error during PITR Recovery

Gnanakumar" <gnanam@zoniac.com> wrote:
 
> what is the correct method of upgrading/installing to 8.2.17?
> 
> Let me make the question/idea, which I'm thinking in my minding of
> upgrading, clear here:
> 
> 1. Rename '/usr/local/pgsql/data' to '/usr/local/pgsql/data.old'
> 2. Install v8.2.17 to its default from the source (Because
> installing from source is comfortable for me)
> 3. After installation, just remove '/usr/local/pgsql/data' and
> rename '/usr/local/pgsql/data.old' to '/usr/local/pgsql/data'
> 4. Start server.  It should have become v8.2.17
 
There are so many ways to do this, particularly since you are
comfortable installing from source, that I'll just tell you how we
do it and let you adjust as needed for your shop.
 
1. We build from source with a version-specific prefix (for example:
/usr/local/pgsql-8.4.4).  We always point to a particular executable
in our service scripts, but create a symbolic link to the one we
want as the default client; the bin directory of that symlink is put
onto our path.  We do like to initdb a test cluster and confirm that
our custom functions all got created properly and seem to be working
before moving on.
 
2. Once the new minor version is installed, we point the service
script to it for the database we're about to upgrade.
 
3. We always make sure we're backed up, but since we use PITR
techniques with archiving always active, that's no big deal.
 
4. We do a service stop followed by a service start (*not* a
restart!) to start using the new version.
 
5. We do any post-upgrade steps, like any needed REINDEX.
 
I'm not sure why you needed that rename dodge that you mentioned,
but you know your environment better than I do.
 
-Kevin