Ryan Lowe <rl...@pablowe.net> writes:
> Thanks for all the responses, but I think I'm being unclear here. Let's
> walk through this case step-by-step. I start with a happy instance of
> Postgres:
This example does not have anything to do with the actual behavior of
Postgres, at least not on any system I know about. Killing the
postmaster does not cause child backends to die, and it certainly
doesn't cause them to commit open transactions and then die.
The system would be quite seriously broken if it acted as you describe.
I tested this, just to see if somebody had broken it when I wasn't
looking. The behavior that I see here is:
1. Killing the postmaster doesn't affect open transactions.
2. Killing the specific backend prevents the transaction from committing.
Which is what I expected.
> ... There has been talk in this thread
> that the application should simply always try and validate that its
> transactions have in fact failed, but that is not a feasible solution (for
> many reasons). Thoughts?
You might wish to believe that you can ignore the problem, but you can't.
No matter what Postgres does or doesn't do, external issues such as
network failures can create the problem of a transaction possibly being
committed while the client remains in doubt whether it happened or not.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
