Обсуждение: Running 9 in production? Sticking with 8.4.4 for a while?
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? Just looking for 9.0 feedback (understand it's still quite new). Thanks Tory
Tory, We will continue to test under 9.0 but will keep production at 8.4.4 for a while longer as we want to see what kinds of issues show up over the next few weeks with 9.0. 9.0 has some features we would like to use but it isn't worth the risk of production. I think that the PostGres team has one of the best develop and test cycle management systems but there is always things that are going to pop up after a release. It just depends on the level of pain your willing to suffer. It seems that the developers are able to track down and kill bugs in a timely manner so I would expect to see a 9.0.1 version in the near future. At that point we'll start doing a lot more tire kicking. Best Regards Mike Gould "Tory M Blue" <tmblue@gmail.com> 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? > > Just looking for 9.0 feedback (understand it's still quite new). > > Thanks > Tory > > -- > Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Michael Gould, Managing Partner Intermodal Software Solutions, LLC 904.226.0978 904.592.5250 fax
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@2ndQuadrant.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
On 9/28/2010 4:45 PM, Greg Smith wrote: > 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. A conservative approach is never to use version x.0 of *anything*. The PG developers are very talented (and also very helpful on these mailing lists - thanks for that), but they are human. For work I'm paid to do (as opposed to my own or charity work), I like to stay at least one point release behind the bleeding edge. -- Guy Rouillier
On Tue, Sep 28, 2010 at 3:14 PM, Guy Rouillier <guyr-ml1@burntmail.com> wrote: > On 9/28/2010 4:45 PM, Greg Smith wrote: >> >> 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. > > A conservative approach is never to use version x.0 of *anything*. The PG > developers are very talented (and also very helpful on these mailing lists - > thanks for that), but they are human. For work I'm paid to do (as opposed > to my own or charity work), I like to stay at least one point release behind > the bleeding edge. > > -- > Guy RouillierG Thanks guys, truly appreciate the length to which you replied. I like hearing the theory and reasoning behind ones decision. It sounds like my general theory of waiting is shared amongst the group. I can't really absorb large issues in production, so I'll throw the .4 release of 8.4 out and be happy for a while. I'm using slony, so it will take a ton of testing and time to look over and test the 9.0 replication piece, if I even consider making that jump. Thanks for the input, it's appreciated Tory
Tory M Blue writes: > Just looking for 9.0 feedback (understand it's still quite new). Although not 9.0 feedback per se.. but something to consider... I am moving a number of machines from 8.1 to 8.4. We use a rolling procedure with a spare: machine A running 8.1 machine B is prepped with 8.4 change names and IPs keep old A for a bit just in case... The last replacement we noticed a big regression in performance. Upon inspection the machine we replaced was 3.7.. Both 8.X and 8.X have serious problems with a particualr query (dealing with it on performance now). So I guess what I am trying to say... you need to test with your own data set. That lone 8.3.7 machine was literally a fluke. We were going to move all 8.1 to 8.4.. but at one point did one in 8.3. If we had not done that we would not have noticed that both 8.1 and 8.4 have problems with some of our queries. I am even leaning now to have a lab with 8.3 for testing queries.