Re: Thoughts on maintaining 7.3

Joshua D. Drake wrote:
>>eh.. i could see some things, like tsearch2 or pg_autovacuum, which
>>afaik are almost if not completely compatible with 7.3, which will not
>>get back ported. Also fixes in some of the extra tools like psql could
>>be very doable, I know I had a custom psql for 7.2 that back patched the
>>\timing option and some of the pager fixes. now, weather that could be
>>done with stuff closer to core, i don't know...
>
>
> Sure but businesses don't like to upgrade unless they have too. If we
> really want to attract more business to using PostgreSQL then they need
> to feel like they don't have to upgrade every 12 months. Upgrading is
> expensive and it rarely goes as smoothly as a dump/restore.

I have made the following experience:

If a new application is deployed and if it stays unchanged 99% of all
bugs in the database or the software itself will be found within a
comparatively short amount of time.
If a business partner decides to continue to work on his application
(which means changing it) he will accept new PostgreSQL releases.
Up to now upgrading PostgreSQL has never been a problem because have
expected major releases to be stable. In addition to that dump/restore
worked nicely.
I remember having slightly more work when we switched to 7.3 because
somehow type casts are handled differently (less implicit casts - I
think that was the problem) but for that purpose intelligent customers
have testing environments so that nothing evil can happen on the
production system.

I don't think back porting features is a good idea. As Marc said:
PostgreSQL is the kernel and not an ordinary package.
Personally I think that a database product should always be a rock solid
product. Unless applications such as, let's say, xclock, database are
truly critical and customers won't forget about releases eating data.
However, in my opinion they can understand that maintenance is necessary.

> When you deal with the systems I do, the cost to a customer to migrate
> to 7.4 would be in the minimum of 10,000-20,000 dollars.
> They start to ask why were upgrading with those numbers.

What did you do to cause these costs?????
We have several huge and critical customers as well but none of them
would cause costs like that.

If everything works nicely: Why would you change the release anyway? Why
would you back-port new features if you don't accept downtimes?

If something has been working for months there are not that many bugs
you can expect. In case of disaster there are still options to fix bugs.
That's what commercial guys are here for.
Fortunately we haven't ever seen a situation in which something really
severe has been broken.

Buffer overflows:
Usually this kind of bugs can be fixed within just a few lines.

I have been working with PostgreSQL for 4 years now. All together I have
encountered 3-4 bugs which caused me some headache and which I haven't
known. I guess 1 per year is more than acceptable.

Regards,

Hans

--
Cybertec Geschwinde u Schoenig
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/2952/30706 or +43/660/816 40 77
www.cybertec.at, www.postgresql.at, kernel.cybertec.at