"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes:
> Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Huh? If the backend dumped core before you sent it the commit,
>> the data will certainly not be committed. It might be physically
>> present on disk, but it won't be considered valid.
> I suppose that there is a window of time between the commit becoming
> effective and the return to the application which, from a user
> perspective, would be hard to distinguish from what the OP
> described. I don't really see how that can be avoided, though,
> short of a transaction manager using 2PC. Any time the server
> crashes while a COMMIT is pending, one must check to see whether it
> "took".
Yeah, a post-commit crash leaves you in doubt about whether the commit
"took", but you get into byzantine-generals issues as soon as you try to
design that out. Consider the possibility that the commit went fine but
the network eats the reply packet saying so. Really, any application
that is constructed to reconnect and retry has got to have logic to test
whether the commit occurred, not just assume that it did or didn't.
(2PC is hardly a magic bullet for this, either.)
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
