Re: Commercial support, was Re: [HACKERS] v6.4.3 ?

Jan Wieck wrote:
> 
> Terry Mackintosh wrote:
> 
> >
> > Hi all
> >
> > > >     That's  the  reason.  One  of  the  biggest drawbacks against
> > > >     Postgres is (for many companies at least), that you can't buy
> > > >     support.
> >
> > IMHO ...
> >
> > Well, yes one can, one may just need to look around a bit... and pay
> > commercial support prices.
> >
> > Example:
> > As for my self I feel confident that I could provide such support, having
> > been using Postgres+ since Postgres 0.95? (3?4 years ago?).  I charge
> > $25/hour, but have been considering going to $30/hour. While I've yet to
> > get a PostgreSQL specific job, I have had some other Linux based jobs.
> >
> > [...]
> 
>     Nice idea.
> 
>     But a word of caution seems appropriate.
> 
>     Commercial  support  doesn't  mean  only  that  you  can hire
>     someone who takes care about your actual  problems  with  the
>     product.  It also means that there is someone you can bill if
>     that product caused big damage to you (product warranty).
> 
>     Commercial support doesn't mean only that you hire someone on
>     a  T/M  base  (time and material). It also means that you can
>     sign a support contract  with  a  regular  payment  and  have
>     written  down  response-  and  maximum  problem-to-fix times,
>     escalation levels etc.
> 

Usage decisions also depend on one other MAJOR factor, which Linux has
conquered, but I personally feel that PostGres is still a bit shy on:
reliability.  We use PostGres commercially, and quite frankly have a
tough time with it, because of consistent failures with it. Although
the price is right, and we hope to stick with PostGres as it matures
into a more robust product, others would not touch it when you consider
the following reliability problems (admittedly all reported on 6.3):

   1. Tables "disappearing" while still listed in the db directory
      (but no longer visible from the client)
   2. Tables being corrupted (i.e. not selectable, not vacuumable,
      not exportable)
   3. Vacuum commands that take longer to run after one day of table
      updates than if the table was to be dumped and reloaded
      (e.g. table with 1.7 million rows, 200,000 rows being updated
      each day)
   4. An inability to run multiple clients simultaneously without
      having the backends choke and kick everybody out (we've had
      to implement a lock manager that restricts db access to one
      client at a time) (Part of the test suite should be an 8 hour
      or so load test that has multiple clients reading/writing
      to the same/different tables...might be surprised what you
      find)
   5. Memory leaks/poor mem management in various components that need 
      to be worked around (vacuum, insert of existing rec into
      uniquely indexed table)
   

Linux is successful because it is reliable, and because many folks are
WILLING to  risk an OS that has the perception of being
unsupported, if once they install it it will run cleanly.  However,
anyone using a database for any sort of serious application will
generally have a more stringent set of criteria that they apply to
their selection process. I.e. PostGres is tackling a tougher market
than Linux is tackling, and it will have to be correspondingly more
mature in order to enjoy the same success.

Reword? We would be happier if someone were to iron all the problems
out of postgres that make it unreliable, and not very robust, than
if someone were to provide commercial support (which will NOT fix
the aforementioned problems!)

Thomas
------------------------------------------------------------
Thomas Reinke                            Tel: (416) 460-7021
Director of Technology                   Fax: (416) 598-2319
E-Soft Inc.                         http://www.e-softinc.com