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