8.3b1 in production?

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:

"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.3server)

. 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.1server 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