Thread: 9.1 to 9.2 requires a dump/reload?
I was just looking at http://www.postgresql.org/docs/devel/static/release-9-2.html and it mentioned that a dump/reload cycle was required to upgrade from a previous release. I just got done telling some of my coworkers that PG had been bitten by this enough times that they were done with it. Am I wrong? Is this normal?
I see that pg_upgrade is an option. Having never used how long should I expect pg_upgrade to take? Obviously we'll measure it in our environment, but it'd be nice to have a ballpark figure.
Nik
pg_upgrade has worked fine for several releases. I believe that the only time when pg_upgrade isn't a viable option is for some types of GIST indices. On Mon, Oct 22, 2012 at 2:55 PM, Nikolas Everett <nik9000@gmail.com> wrote: > I was just looking at > http://www.postgresql.org/docs/devel/static/release-9-2.html and it > mentioned that a dump/reload cycle was required to upgrade from a previous > release. I just got done telling some of my coworkers that PG had been > bitten by this enough times that they were done with it. Am I wrong? Is > this normal? > > I see that pg_upgrade is an option. Having never used how long should I > expect pg_upgrade to take? Obviously we'll measure it in our environment, > but it'd be nice to have a ballpark figure. > > Nik -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ L. Friedman netllama@gmail.com LlamaLand https://netllama.linux-sxs.org
On Monday, October 22, 2012 05:55:07 PM Nikolas Everett wrote: > I was just looking at > http://www.postgresql.org/docs/devel/static/release-9-2.html and it > mentioned that a dump/reload cycle was required to upgrade from a previous > release. I just got done telling some of my coworkers that PG had been > bitten by this enough times that they were done with it. Am I wrong? Is > this normal? > > I see that pg_upgrade is an option. Having never used how long should I > expect pg_upgrade to take? Obviously we'll measure it in our environment, > but it'd be nice to have a ballpark figure. pg_upgrade using hard links should only take a minute or 2. You'll also need to shuffle around packages and services and config files. The slowest part for any decent sized database will be doing an analyze after bringing it up under 9.2, though. So however long that takes for your db, plus maybe 10-15 minutes or so, if you've practiced.
On Mon, Oct 22, 2012 at 6:17 PM, Alan Hodgson <ahodgson@simkin.ca> wrote:
pg_upgrade using hard links should only take a minute or 2. You'll also needOn Monday, October 22, 2012 05:55:07 PM Nikolas Everett wrote:
> I see that pg_upgrade is an option. Having never used how long should I
> expect pg_upgrade to take? Obviously we'll measure it in our environment,
> but it'd be nice to have a ballpark figure.
to shuffle around packages and services and config files. The slowest part for any
decent sized database will be doing an analyze after bringing it up under 9.2,
though. So however long that takes for your db, plus maybe 10-15 minutes or
so, if you've practiced.
Yikes! Analyze will certainly take the longest time - we'll have to build some kind of strategy for which tables to analyze first and how many to analyze at once.
Thanks for letting me know.
Nik
On Tue, Oct 23, 2012 at 7:41 AM, Nikolas Everett <nik9000@gmail.com> wrote: > On Mon, Oct 22, 2012 at 6:17 PM, Alan Hodgson <ahodgson@simkin.ca> wrote: >> >> On Monday, October 22, 2012 05:55:07 PM Nikolas Everett wrote: >> > I see that pg_upgrade is an option. Having never used how long should I >> > expect pg_upgrade to take? Obviously we'll measure it in our >> > environment, >> > but it'd be nice to have a ballpark figure. >> >> pg_upgrade using hard links should only take a minute or 2. You'll also >> need >> to shuffle around packages and services and config files. The slowest part >> for any >> decent sized database will be doing an analyze after bringing it up under >> 9.2, >> though. So however long that takes for your db, plus maybe 10-15 minutes >> or >> so, if you've practiced. > > > Yikes! Analyze will certainly take the longest time - we'll have to build > some kind of strategy for which tables to analyze first and how many to > analyze at once. Note that if you nearly zero downtime, then slony is really the only answer.
On Tue, Oct 23, 2012 at 09:41:20AM -0400, Nikolas Everett wrote: > On Mon, Oct 22, 2012 at 6:17 PM, Alan Hodgson <ahodgson@simkin.ca> wrote: > > On Monday, October 22, 2012 05:55:07 PM Nikolas Everett wrote: > > I see that pg_upgrade is an option. Having never used how long should I > > expect pg_upgrade to take? Obviously we'll measure it in our > environment, > > but it'd be nice to have a ballpark figure. > > pg_upgrade using hard links should only take a minute or 2. You'll also > need > to shuffle around packages and services and config files. The slowest part > for any > decent sized database will be doing an analyze after bringing it up under > 9.2, > though. So however long that takes for your db, plus maybe 10-15 minutes or > so, if you've practiced. > > > Yikes! Analyze will certainly take the longest time - we'll have to build some > kind of strategy for which tables to analyze first and how many to analyze at > once. pg_upgrade 9.2 creates a script that incrementally produces more accurate statistics, which should help. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Hello Can you remember where did you read that? There is no mention of GIST on http://www.postgresql.org/docs/9.2/static/upgrading.html and a database which uses GIST indexes *seems* to work just finde after upgrading with pg_upgrade. bye, -christian- Am Mon, 22 Oct 2012 15:02:13 -0700 schrieb Lonni J Friedman <netllama@gmail.com>: > pg_upgrade has worked fine for several releases. I believe that the > only time when pg_upgrade isn't a viable option is for some types of > GIST indices. > > On Mon, Oct 22, 2012 at 2:55 PM, Nikolas Everett <nik9000@gmail.com> > wrote: > > I was just looking at > > http://www.postgresql.org/docs/devel/static/release-9-2.html and it > > mentioned that a dump/reload cycle was required to upgrade from a > > previous release. I just got done telling some of my coworkers > > that PG had been bitten by this enough times that they were done > > with it. Am I wrong? Is this normal? > > > > I see that pg_upgrade is an option. Having never used how long > > should I expect pg_upgrade to take? Obviously we'll measure it in > > our environment, but it'd be nice to have a ballpark figure. > > > > Nik > > >
On Sat, Nov 24, 2012 at 06:03:32PM +0100, Christian Hammers wrote: > Hello > > Can you remember where did you read that? There is no mention of GIST on > http://www.postgresql.org/docs/9.2/static/upgrading.html and a database > which uses GIST indexes *seems* to work just finde after upgrading with > pg_upgrade. Hash, Gin, and GiST index binary format had changes from 8.3->8.4. Running pg_upgrade or pg_upgrade --check will warn about any indexes that need rebuilding. If pg_upgrade didn't report any problems, you are fine. --------------------------------------------------------------------------- > > bye, > > -christian- > > > Am Mon, 22 Oct 2012 15:02:13 -0700 > schrieb Lonni J Friedman <netllama@gmail.com>: > > > pg_upgrade has worked fine for several releases. I believe that the > > only time when pg_upgrade isn't a viable option is for some types of > > GIST indices. > > > > On Mon, Oct 22, 2012 at 2:55 PM, Nikolas Everett <nik9000@gmail.com> > > wrote: > > > I was just looking at > > > http://www.postgresql.org/docs/devel/static/release-9-2.html and it > > > mentioned that a dump/reload cycle was required to upgrade from a > > > previous release. I just got done telling some of my coworkers > > > that PG had been bitten by this enough times that they were done > > > with it. Am I wrong? Is this normal? > > > > > > I see that pg_upgrade is an option. Having never used how long > > > should I expect pg_upgrade to take? Obviously we'll measure it in > > > our environment, but it'd be nice to have a ballpark figure. > > > > > > Nik > > > > > > > > > -- > Sent via pgsql-general mailing list (pgsql-general@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +