Re: Safely Killing Backends (Was: Applications that leak connections)

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