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:
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 ourenvironment,
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.
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 ourenvironment,
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>:
Show quoted text
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. +