Scott Marlowe wrote:
> On Tue, Mar 11, 2008 at 7:33 PM, Justin <justin@emproshunts.com> 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.
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.
Regards
Russell
