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@ESI.it
