Robert Haas <robertmh...@gmail.com> writes: > On Wed, Feb 3, 2016 at 3:41 PM, Jim Nasby <jim.na...@bluetreble.com> wrote: >> Wouldn't it be more sensible to just roll the transaction back and not >> disconnect?
> It would be nice to be able to do that, but the client-server protocol > can't handle it without losing sync. Basically, if you send an error > to an idle client, you have to kill the session. This has come up > many times before. Well, you can't just spit out an unprompted error message and go back to waiting for the next command; as Robert says, that would leave the wire protocol state out of sync. But in principle we could kill the transaction and not say anything to the client right then. Instead set some state that causes the next command from the client to get an error. (This would not be much different from what happens when you send a command in an already-reported-failed transaction; though we'd want to issue a different error message than for that case.) I'm not sure how messy this would be in practice. But if we think that killing the whole session is not desirable but something we're doing for expediency, then it would be worth looking into that approach. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers