Re: [PATCH] V3: Idle in transaction cancellation

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> 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.

> What about some other message that's not a query?

There aren't any (I'm using a loose definition of "query" here --- any
client request counts).

>> You can only send one, and in that situation you probably want the
>> cancellation to be reported.

> What about an elog or ereport with severity < ERROR? Surely there
> must at least be provision for multiple non-error messages per
> transaction.

You can send NOTICEs freely, but downgrading an error to a notice is
probably not a great solution --- keep in mind that some clients just
discard those altogether.

>> 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.

> We already have pg_terminate_backend() and pg_cancel_backend(). Are
> you imagining a general mechanism like pg_rollback_backend()?

No, not really, I'm just concerned about the fact that it's trying to
send a message while in DoingCommandRead state. FE/BE protocol
considerations aside, that's likely to break if using SSL, because who
knows where we've interrupted openssl. In fairness, the various
pre-existing FATAL-interrupt cases have that problem already, but I was
willing to live with it for things that don't happen during normal
operation.

regards, tom lane