On Fri, 4 Feb 2005, Jim Wilson wrote:
regards, tom lane
We\'d like to be able to take out a connection without risking postmaster going down and thus losing all uncommitted data.
Unfortunately the whole world isn\'t encapsulated in Postgres transactions or we would never have to worry about uncommitted data. Just because your tables are in sync, and your applications are designed in a way that coordinates with real world events and/or multiple entity transactions (e.g. electronic payments) as well as possible, doesn\'t mean that data integrity isn\'t put at risk by the loss of uncommitted information.
I'm sorry, but I cannot make any sense out of the last sentence. By definition, data integrity refers only to committed data. Uncommitted data is not data at all, for both the parties involved. The server may receive a rollback anytime (which is not a delete!) and the client may get an error from the server, even at commit time (the last step). The network may go down in the middle of it. _Anything_ may happen. If your application is not able to handle a failure _before_ commit time, you should fix it.
This "problem", which is always there for the application designer, is exasperated when the whole server goes down because of an admin who, as delicately as possible, is just trying to remove an orphaned connection that\'s blocking transactions. Would I stop using Postgres if this was never changed? No way. Do I think it could be better than it is? Absolutely. For our purposes, it would be more important than some things like further query optimization, etc., that would be at the top of other user\'s lists.
I think that the most important thing, for your purpose, as an "application designer", is to fix your application. There's no such a thing as "uncommitted data", it's not an intermediate state, it's not some kind of "less important" data. Let T be the commit time, before T there's _nothing_ and after T there's _everything_ (all of it). That's the A in ACID.
Your application should handle failures in the middle of a transaction, connection failures included, in a graceful but correct way.
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
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@xxxxxx---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
