Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Dec 16, 2010 at 11:58 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> It's possible we could refactor things so we abort the open transaction
>> while inside the interrupt handler, then queue up an error to be
>> reported whenever we next get a command (as envisioned in part 0003),
>> then just return control back to the input stack. �But things could get
>> messy if we get another error to be reported while trying to abort.
> This is along the lines of what Andres and I have already been groping
> towards upthread. But the question of what to do if another error is
> encountered while trying to abort the transaction is one that I also
> thought about, and I don't see an easy solution.
Yeah, it's a bit messy, because you really can't send multiple ERROR
messages to the client when it next sends a query: the protocol says
there'll be at most one. We could either discard all but the first
(or last?) of the queued error events, or add code to elog.c that
somehow merges them into one error event, perhaps by adding info
to the DETAIL field. I'm handwaving there --- I think probably the
first cut should just discard errors after the first, and see how
well that works in practice.
> Another thing I don't quite understand is - at what point does the
> protocol allow us to emit an error?
Basically, you can send an error in response to a query. In the current
FATAL cases, we're cheating a bit by sending something while idle ---
what will typically happen at the client end is that it will not notice
the input until it sends a query, and then it will see the
already-pending input, which it will think is a (remarkably fast)
response to its query. Or possibly it will bomb out on send() failure
and not ever consume the input at all. But if we want to keep the
connection going, we can't cheat like that.
> Suppose that the transaction gets
> cancelled due to a conflict with recovery while we're
> DoingCommandRead, and then the user now sends us "SELCT 2+2". Are we
> going to send them back both errors now, or just one of them? Which
> one?
You can only send one, and in that situation you probably want the
cancellation to be reported.
FWIW, I'm not too worried about preserving the existing
recovery-conflict behavior, as I think the odds are at least ten to one
that that code is broken when you look closely enough. I do like the
idea that this patch would provide a better-thought-out framework for
handling the conflict case.
regards, tom lane