Re: 8.3b1 in production?

From: "Peter Childs" <peterachilds(at)gmail(dot)com>
To:
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: 8.3b1 in production?
Date: 2007-10-25 14:32:07
Message-ID: a2de01dd0710250732o6ef6defcp8d05062eee4a4dfa@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 24/10/2007, Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
>
> "rihad" <rihad(at)mail(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2007-10-25 14:34:38 Re: [PGSQL v8.2.5] Similar queries behave differently
Previous Message Tom Lane 2007-10-25 14:30:40 Re: select count() out of memory