Re: [GENERAL] Re: Is PostgreSQL ready for mission criticalapplications? - Mailing list pgsql-general

>  The
> : thing is PostgreSQL is extremely reliable if u know what you are doing
and
> : know how to handle/get around any bugs.
>
> Sorry, this is simply not true. We are talking about reliability here and
> not about some features that might be difficult to find for the
inexperienced
> user or something like that. For instance, I had to fight with PostgreSQL
and
> Perl to get Notify to work. It might be difficult to get this to work,
because
> the lack of documentation or bugs in the way it is implemented, but I got
> it to work. This is the thing a beginner stumbles over, and if not
persistent
> enough will label as a bug, although it might be only the documentation
that
> is buggy, or his level of understanding of the workings of the database is
> just not good enough.

> But I am not imagining the random "I have rolled back the current
transaction
> and am going to terminate your database system connection and exit."
messages.
> If there is a way to kill a database as a normal user, it is not reliable.
> Maybe, if I knew more about PostgreSQL, I would be able to not trigger the
> bugs, but that is not the point. The bugs should not be there or there
> should be at least a meaningful error message saying: "I am sorry Dave, I
can't
> let you do this, because it would trigger a bug." I have seen random
chrashes
> without any indication to the problem and I have seen strange messages
> hinting at a problem deep down in a btree implementation or something like
> that. And the worst thing is, that these bugs are not repeatable in a way
> that someone could start debugging them or at least work around them.

I guess I can see that point :)  The ability for a less experienced user or
admin to reasonably do a task in a short amount of time without srewing
things up is more a factor of ease of use than reliability...The ease of
accidentally causing serious harm to the integrity of a database that
requires major repair (foolproofing) is a factor of reliability ;)


> and not on disk, in case of a database failure. I thought that this is
enough,
> because databases are supposed to be more reliable then simple
filesystems...

No only more flexible ;)   Not much is more reliable than a flat file...just
you have to write all the routines to handle multiple users accessing the
file and routines to indeex and find what you are looking for :)

> While this is generally true, a huge database can have an impact on
> stability. For instance, if you have a very small memory leak, it will not
> show in small databases but might show in big ones, triggering a bug. Or
> an index grows over some bound and a hash file has to be increased or
whatever.
> And there are some problems of this kind in PostgreSQL. I am logging all
> logins and logouts from a radius server into PostgreSQL and after it ran
> well for several months, it slowed to a crawl and vacuum wouldn't work
> anymore. So, yes, I do have a lot of inserts, although about 6000 inserts
a
> day and a total of a few hundert thausend records is not really much.

What version of PostgreSQL did this occur on?  And how often were you
running vacuums?


> My question of an earlier posting is still not answered. Does anybody
here,
> who reported PostgreSQL to be very stable, use advanced features like
pl/pgsql
> procedures, triggers, rules and notifies? Lets have a show of hands. I
would
> really like to know, why I am the only one having problems. :-) Although
> it might be, because, as this is a PostgreSQL mailing list, most of the
> readers are people who are happy with PostgreSQL, because all the others
> have left and are on an Oracle list now. :-)

:)
 In reference to your other posting...if you are experienced enough to
understand the inner workings of PostgreSQL.  You are experienced enough to
DBA Oracle yourself ;)  Dont waste your money hiring a $100,000 certified
DBA (unless u need the extra help)  ;)




************