Re: [PATCH] V3: Idle in transaction cancellation

On Wednesday 15 December 2010 15:40:20 Robert Haas wrote:
> On Wed, Dec 15, 2010 at 7:47 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I thought about doing that first. Btw, LOG_NO_CLIENT is just a more
> > abstracted way of what COMERROR did before...
>
> Hmm, but it must not be quite the same, because that didn't require
> the silent_error_while_idle flag.
True. Thats a separate thing.

> >> Yeah. I'll try to find some time to think about this some more. It
> >> would sure be nice if we could find a solution that's a bit
> >> conceptually cleaner, even if it basically works the same way as what
> >> you've done here.
> >
> > I would like that as well. I am not sure you can achieve that in a
> > reasonable amount of work. At least I couldn't.
> 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.
Currently there are no other locations where we errors could get thrown at
that point but I see where youre going.

You could use "DoingCommandRead" to solve that specific use-case, but the
COMERROR ones I don't see as being replaced that easily.
We could introduce something like

NoLogToClientBegin();
NoLogToClientEnd();
int NoLogToClientCntr = 0;

but that sounds like overdoing it for me.

Andres