Robert Haas <robertmh...@gmail.com> writes:
> On Thu, Dec 16, 2010 at 12:46 PM, Tom Lane <t...@sss.pgh.pa.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
