On Wed, Mar 12, 2008 at 12:02 AM, Russell Smith <mr-russ@xxxxxxxxxx> wrote: > > Scott Marlowe wrote: > > On Tue, Mar 11, 2008 at 7:33 PM, Justin <justin@xxxxxxxxxxxxxxx> wrote: > > > >> I view updates/patches of any kind like this, if ain't broke don't fix it. > >> I normally only update computers with security patches only after i prove it > >> don't destroy installs. > >> > > > > But that's juast it. When a postgresql update comes out, it is > > precisely because the database IS broken. A bug that might eat your > > data or allow an attacker to get into your database are the kinds of > > fixes, and the only kind really, that go into production pgsql > > releases. I too wait a day or two to test it on a staging server, but > > I've never had a pgsql update blow back in my face, and I've done an > > awful lot of them. > > > So you missed 8.1.7 then or weren't using those features at the very least? > You also didn't have the stats collector issue with 8.2.3, 8.2.4 took > quite some time to come out. > And remember the policy violation when 8.0 came out, we replaced the > buffer expiry algorithm with a patch release. Yeah, we went from 8.0.x (whatever was current at the time) to 8.2.4. And I do test any update for a couple days before applying it. So when something goes wrong with a release like 8.1.7 was, I suppose, I get the next one and I'm good. I don't just throw updates at production. But I've never been bitten by an update that was more than a couple days old either. And I remember the change in 8.0 in the cache control, and it definitely caused me to be slow on updating at that time, to make sure it worked. It was very well advertised though, so I don't feel like a surprise was sprung upon me. > PostgreSQL is not perfect, but as you can see by the problems with 8.1.7 > the next update was released very very quickly. Sometimes I fear we > pump up our status a little too far with the reliability and only > perfectly patched releases. The real key is what's the response when > things go wrong, because things will go wrong at some point. I think we > need to be careful because it's a much bigger fall the higher the > pedestal we put ourselves on. Agreed. I do think though that the pg developers have gotten much much better about such things as time has gone by. I don't get the feeling MySQL has. The difference is very much in how one handles one's mistakes, and in that arena, I feel like pgsql has fewer in production releases and they fix them much quicker, which is a combination I can live with. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
