On Tue, 8 Feb 2005, Jim Wilson wrote:
>>
>> Your application should handle failures in the middle of a
> transaction,
>> connection failures included, in a graceful but correct way.
>
> It does very well, until the next bug is discovered.
>
>>
>> I see your point (being able to safely shut a connection down on the
>> server side), but it\'s at the _bottom_ of any list.
>>
>> .TM.
>> --
>> / / /
>> / / / Marco Colombo
>
> That\'s unfortunate. I\'ve tried to explain my position off list to
> Marco,
> but it really isn\'t worth debating. FWIW I think this thread was
> started
> by someone with application issues. The fact is, such things happen.
>
> Unfortunately Marco choses speaks for "any list" and I\'ll just
> repeat that I find this instability issue the most significant drawback
>
> for Postgres installations. This doesn\'t mean that there aren\'t other
> areas
> of priority for other users. And no, I do not want to debate the
> meaning
> of the word "instability". :-)
>
> Best regards,
>
> Jim Wilson
As I wrote in private mail, authenticated clients have many means to
perform a DoS attack (whether intentionally or not). Most of cases
can be handled only with a server restart. To put simply, PostgreSQL
is not designed to handle hostile clients well.
IMHO, a friendly enviroment (client behaviour) is a safe assumption
for a RDBMS. It's not its job to paperbag over application bugs.
Anyway, I agree in ending this thread.
I recognize we have different meanings for "instability" and "data loss".
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it