On Tue, 8 Feb 2005, Jim Wilson wrote:
transaction,
Your application should handle failures in the middle of aconnection 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@xxxxxx---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
