Re: Running 9 in production? Sticking with 8.4.4 for a while?

Tory M Blue wrote:
> I'm doing an OS upgrade and have been sitting on 8.4.3 for sometime. I
> was wondering if it's better for the short term just to bring things
> to 8.4.4 and let 9.0 bake a bit longer, or are people with large data
> sets running 9.0 in production already?
>

I'm aware of two people with large data sets who have been running 9.0
in production since it was in beta. Like most code, what you have to
consider is how much the code path you expect to use each day has been
modified during the previous release. If you're using 9.0 as "a better
8.4", the odds of your running into a problem are on the low side of the
risk curve. But those using the features that are both new and were
worked on until the very end of the development cycle, like the new
replication features, they are much more likely to run into a bug.

There are two main things I've been advising clients to be very careful
about when considering an early 9.0 upgrade mainly as a straight
replacement for 8.4 (making it possible to start testing the replication
stuff too, but not relying on that immediately). The changes to
acceptable PL/pgSQL syntax can easily break some existing procedures;
easy to fix if you find them in testing, but you if you have a lot of
functions in that language you should really do a code audit along with
testing.

The other is that query plans are much more likely to use Materialize
nodes now in ways they never did before. That planning change will be
long-term positive, but I expect to see some short-term performance
regressions in plans that used to work better; not because of the code
itself, just because of Murphy's Law. This is similar to how the hash
aggregation changes made to 8.4 could produce worse plans under
unexpected circumstances than what people saw in 8.3 and earlier, which
is something else you're also exposed to here if your existing code is
running on 8.4. There are less of those situations in the recent 8.4
releases than the early ones, but the possibility of aggressive hashing
being worse than the older approach still happens. I've seen exactly
one of them on a production server running 8.4, and the problem had
already been reported to the relevant list before I got there.

--
Greg Smith, 2ndQuadrant US greg(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance" Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book