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 (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
