On Wed, Dec 15, 2010 at 10:02 AM, Andres Freund <andres@anarazel.de> wrote:
>> Is there a way that errstart() and/or errfinish() can know enough
>> about the state of the communication with the frontend to decide
>> whether to suppress edata->output_to_client? In other words, instead
>> of explicitly passing in a flag that says whether to inform the
>> client, it would be better for the error-reporting machinery to
>> intrinsically know whether it's right to send_message_to_frontend().
>> Otherwise, an error thrown from an unexpected location might not have
>> the flag set correctly.
>
> You could use "DoingCommandRead" to solve that specific use-case, but the
> COMERROR ones I don't see as being replaced that easily.
Well, again, I'm not an expert on this, but why would we need to unify
the two mechanisms? Asynchronous rollbacks (what we're trying to do
here) and protocol violations (which is what COMMERROR looks to be
used for) are really sort of different. I'm not really sure we need
to handle them in the same way. Let's think about a recovery conflict
where ProcessInterrupts() has been called. Right now, if that
situation occurs and we are not DoingCommandRead, then we just throw
an error. That's either safe, or an already-existing bug. So the
question is what to do if we ARE DoingCommandRead. Right now, we
throw a fatal error. There's no comment explaining why, but I'm
guessing that the reason is the same problem we're trying to fix here:
the protocol state gets confused - but if we throw a FATAL then the
client goes away and we don't have to worry about it any more. Our
goal here, as I understand it, is to handle that case without a FATAL.
So let's see... if we're DoingCommandRead at that point, and
whereToSendOutput == DestRemote then we set whereToSendOutput =
DestNone before throwing the error, and restore it just after we reset
DoingCommandRead? <stabs blindly at target>
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company