> Jim Wilson <jimw@kelcomaine.com> writes:
> > Rather than getting into the raised eyebrow thing , I\\\\\\\'d
suggest
> > checking your "qualifiers". Consider that with Postgres, if killing
a
> > single connection brings the whole server down, you will loose
_all_
> > uncommitted data. If you did not, then I would call that a bug.
>
> I would too. So what\'s your complaint exactly? That kill -9\'ing
one
> backend takes out all your current uncommitted transactions and not
just
> the one? I don\'t regard that as data loss: uncommitted is
uncommitted.
>
> 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.
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.
Best regards,
Jim