Thread: 8.3b1 in production?
Hi, Does anyone have an idea how risky it is to start using 8.3b1 in production, with the intention of upgrading to release (or newer beta) as soon as it becomes available? Risky compared to running a release, that is. Beta -> release upgrades might be less tricky than 8.2 -> 8.3. Thank you.
rihad <rihad@mail.ru> writes:
> Does anyone have an idea how risky it is to start using 8.3b1 in
> production, with the intention of upgrading to release (or newer beta)
> as soon as it becomes available? Risky compared to running a release,
> that is. Beta -> release upgrades might be less tricky than 8.2 -> 8.3.
At this point you're guaranteed to need a dump/reload between beta1 and
beta2 ...
regards, tom lane
On Wednesday 24 October 2007 09:59:20 rihad wrote: > Hi, > > Does anyone have an idea how risky it is to start using 8.3b1 in > production, with the intention of upgrading to release (or newer beta) > as soon as it becomes available? Risky compared to running a release, > that is. Beta -> release upgrades might be less tricky than 8.2 -> 8.3. > I'm pretty sure b2 is going to require a fresh initdb (due to bugs found). So I'd advice against that. > Thank you. jan > > ---------------------------(end of broadcast)--------------------------- > TIP 5: don't forget to increase your free space map settings -- -------------------------------------------------------------- Jan de Visser jdevisser@digitalfairway.com Baruk Khazad! Khazad ai-menu! --------------------------------------------------------------
"rihad" <rihad@mail.ru> writes: > Hi, > > Does anyone have an idea how risky it is to start using 8.3b1 in production, > with the intention of upgrading to release (or newer beta) as soon as it > becomes available? Risky compared to running a release, that is. Beta -> > release upgrades might be less tricky than 8.2 -> 8.3. Well nobody's going to be able to guess at what problems haven't been found yet. All we can say decisively is what bugs have already been found: . On Windows UTF8 encoding isn't allowed . VACUUM does an unnecessarily large amount of I/O . Toaster could cause failures on machines with strict alignment . Resources limits in Windows limit the number of clients . pg_tablespace_size() on pg_global fails even for superuser . ABI break with old libpq for applications which depend on encoding IDs (such as initdb -- you can't run initdb with an 8.2 libpq against an 8.3 server) . invalid tsvector input could cause crashes . ALTER COLUMN TYPE would reset the index's options, possibly moving it to the default tablespace or worse Also: . A new data type, txid, was added . Several new contrib modules were added to aid tsearch migration . Some tsearch functions were removed or modified . tsearch word categories were redefined and renamed . Make plan invalidation work for dropped sequences (etc) . Be careful to get share lock on each page before computing its free space. . This avoids useless checkpoint activity if XLogWrite is executed when we have a very stale local copy of RedoRecPtr. . Teach planagg.c that partial indexes specifying WHERE foo IS NOT NULL can be used to perform MIN(foo) or MAX(foo) . Remove an Assert that's been obsoleted by recent changes in the parsetree representation of DECLARE CURSOR. Report and fix by Heikki. . Ensure that the result of evaluating a function during constant-expression simplification gets detoasted before it is incorporated into a Const node. . Make dumpcolors() have tolerable performance when using 32-bit chr, as we do . Make "role is not permitted to log in" errors not be hidden . Remove quotes around locale names in some places for consistency. . Add missing entry for PG_WIN1250 encoding, per gripe from Pavel Stehule. Also enable translation of PG_WIN874 -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
On 24/10/2007, Gregory Stark <stark@enterprisedb.com> wrote:
Hmm looks like December release might be a dream then....
I was wondering why my PITR base back up was taking 2 hours on my 8.3 test database where as it takes 50 minutes on 8.1 and the database files are meant to be smaller on a freshly installed 8.3 server rather than a 8.1.1 server that aint been rebuilt since 8.1.1 was newly out.
I was planning to upgrade to 8.3 once its out...
Down time for upgrades is somwhat lacking in a 24x7 business.
Oh my 8.1 server has been up for well over a year with out being down at all. the database for longer which really show how good postgres really is 377 days uptime on computer and I think that was to move a plug.
Peter Childs
"rihad" <rihad@mail.ru> writes:
> Hi,
>
> Does anyone have an idea how risky it is to start using 8.3b1 in production,
> with the intention of upgrading to release (or newer beta) as soon as it
> becomes available? Risky compared to running a release, that is. Beta ->
> release upgrades might be less tricky than 8.2 -> 8.3.
Well nobody's going to be able to guess at what problems haven't been found
yet. All we can say decisively is what bugs have already been found:
. On Windows UTF8 encoding isn't allowed
. VACUUM does an unnecessarily large amount of I/O
. Toaster could cause failures on machines with strict alignment
. Resources limits in Windows limit the number of clients
. pg_tablespace_size() on pg_global fails even for superuser
. ABI break with old libpq for applications which depend on encoding IDs
(such as initdb -- you can't run initdb with an 8.2 libpq against an 8.3 server)
. invalid tsvector input could cause crashes
. ALTER COLUMN TYPE would reset the index's options, possibly moving it to the
default tablespace or worse
Also:
. A new data type, txid, was added
. Several new contrib modules were added to aid tsearch migration
. Some tsearch functions were removed or modified
. tsearch word categories were redefined and renamed
. Make plan invalidation work for dropped sequences (etc)
. Be careful to get share lock on each page before computing its free space.
. This avoids useless checkpoint activity if XLogWrite is executed when we
have a very stale local copy of RedoRecPtr.
. Teach planagg.c that partial indexes specifying WHERE foo IS NOT NULL can be
used to perform MIN(foo) or MAX(foo)
. Remove an Assert that's been obsoleted by recent changes in the parsetree
representation of DECLARE CURSOR. Report and fix by Heikki.
. Ensure that the result of evaluating a function during constant-expression
simplification gets detoasted before it is incorporated into a Const node.
. Make dumpcolors() have tolerable performance when using 32-bit chr, as we do
. Make "role is not permitted to log in" errors not be hidden
. Remove quotes around locale names in some places for consistency.
. Add missing entry for PG_WIN1250 encoding, per gripe from Pavel Stehule.
Also enable translation of PG_WIN874
Hmm looks like December release might be a dream then....
I was wondering why my PITR base back up was taking 2 hours on my 8.3 test database where as it takes 50 minutes on 8.1 and the database files are meant to be smaller on a freshly installed 8.3 server rather than a 8.1.1 server that aint been rebuilt since 8.1.1 was newly out.
I was planning to upgrade to 8.3 once its out...
Down time for upgrades is somwhat lacking in a 24x7 business.
Oh my 8.1 server has been up for well over a year with out being down at all. the database for longer which really show how good postgres really is 377 days uptime on computer and I think that was to move a plug.
Peter Childs
On 10/25/07, Peter Childs <peterachilds@gmail.com> wrote: > I was wondering why my PITR base back up was taking 2 hours on my 8.3 test > database where as it takes 50 minutes on 8.1 and the database files are > meant to be smaller on a freshly installed 8.3 server rather than a 8.1.1 > server that aint been rebuilt since 8.1.1 was newly out. > I was planning to upgrade to 8.3 once its out... > > Down time for upgrades is somwhat lacking in a 24x7 business. > > Oh my 8.1 server has been up for well over a year with out being down at > all. the database for longer which really show how good postgres really is > 377 days uptime on computer and I think that was to move a plug. You should really look at scheduling the 5 minute window up update your 8.1 install. 8.1.1 is quite old and has a few known data eating bugs, if I remember correctly. Updating to 8.1.10 should only take literally about 1 or 2 minutes.
"Scott Marlowe" <scott.marlowe@gmail.com> writes: > On 10/25/07, Peter Childs <peterachilds@gmail.com> wrote: >> I was wondering why my PITR base back up was taking 2 hours on my 8.3 test >> database where as it takes 50 minutes on 8.1 and the database files are >> meant to be smaller on a freshly installed 8.3 server rather than a 8.1.1 >> server that aint been rebuilt since 8.1.1 was newly out. >> I was planning to upgrade to 8.3 once its out... >> >> Down time for upgrades is somwhat lacking in a 24x7 business. >> >> Oh my 8.1 server has been up for well over a year with out being down at >> all. the database for longer which really show how good postgres really is >> 377 days uptime on computer and I think that was to move a plug. > > You should really look at scheduling the 5 minute window up update > your 8.1 install. 8.1.1 is quite old and has a few known data eating > bugs, if I remember correctly. Updating to 8.1.10 should only take > literally about 1 or 2 minutes. Actually 8.1.2 fixed two locale problems which could require reindexing. If you're using plperl functions which play with the locale or a locale like hungarian which compares some different strings as equal then you might have to reindex. Otherwise it's just a Postgres server restart's worth of downtime. There are both data eating bug fixes and security fixes in 8.1.10 for you. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com