Reliabilty, was [GENERAL] Future of PostgreSQL

>
> > once again. The *perception* remains, however, that pgsql still
> > leaves a bit to be desired in the areas of reliability and
> > maintainability. This needs to be remedied. Like I said, progress
> > has been mad, but it appears pgsql isn't quite out of the woods yet.
>
> I keep hearing the old "reliability" argument...there are alot of us using
> PostgreSQL for "mission critical" apps, and haven't seen these
> problems. Can you provide more details on this? I'm not doubting that
> you are hitting a "little known bug" that makes PostgreSQL unreliable for
> you, but without details, we have no way of diagnosing and improving it...
>
> ************

As an org that uses postgres as _THE_ SQL database for our activities,
I'll provide some details about our reliability problems:

1) Up front, I'll state that we use 6.3, so a number of
the technical glitches may have been solved since...

2) We could never reliably use multiple tasks accessing
the database at the same time. I could _reliably_
crash a back-end (and thus cause all back-ends to quit)
by having 3-4 tasks actively doing inserts, updates,
and selects. (Our workaround - a db semaphore built
into our apps that allow only single tasks at a time
to access the db)

3) We cannot use vacuum. Why? Because it takes indefinitely
longer to vacuum a database than it does to dump and
reload. An example case: a table declared as
fld1 varchar(80), fld2 int4, fld3 varchar(32),
fld4 varchar(80), fld5 varchar(20)
with indices
unique index index1 on table(fld1, fl2)
index index on table(fld3)

We have NEVER been able to successfully vacuum the
table after only one day of churn through the database,
churn being defined as 600,000 updates of fld3,fld4 and fld5
in a table with 2 million rows. (Heap assertion error given,
on a system with 128Meg Ram, and 96Meg swap space.)

4) We could never get any answers to reliability related
questions answered by any of the development team or
by anyone else on the various postgres discussion groups. We
would ask the question, post the relevant error log
message, describe the scenario we thought cause the
problem, and it's as if the question disappeared into
a black hole.

Believe it or not, it's actually item #4 that annoys us
the most. Work arounds are a pain, but at least they
accomplish something - the problem no longer occurs.
But when you bang your head against a problem, and no
one seems to have heard of the issue ever, or even
acknowledges the post in question, it definitely
detracts from the value of the product.

Case in point: a long time ago we found a problem affecting
insertions into the database - doing many inserts (I believe
where the record already existed) caused a memory leak when
the insert was rejected due to duplicate index entries.
This forced us to inject a drop/reconnect sequence into the
code to avoid using up all of our memory. We asked about
the problem - no response; we posted the bug in the PR
database - no response; 6 months later, we saw someone
else ask the exact same question (not sure of release,
i thought he was on 6.4, but don't hold me on that one).

It's that kind of non-responsiveness that in our mind makes
the db reliability an issue.

Now don't get me wrong - I realize that you get what you
pay for. But I believe in at the very least responding
to user's questions/problems. A simple "We've seen/not seen
that problem before, and haven't had the time to track down
the root cause and fix it." would have been much
preferable, and gone a long way to making us feel that
problems are being addressed for subsequent releases.

Cheers, Thomas
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com