Re: Logging conflicted queries on deadlocks

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> I think we should report to the client where it is not a security
> breach, and to the server log otherwise.

Well, the point of my original comment is that it's not always so
obvious what might be a security breach or not.

> I'm not sure about warts. A separate server-only context field perhaps?
> Or a separate flag in ErrorData elements saying whether each particular
> one should go to server only.

Yeah, one or the other. I was actually thinking about a server-only
addition to the detail field, because using CONTEXT for this doesn't
really seem like quite the right thing --- if the deadlock occurs inside
a function or some other place where lines will get appended to CONTEXT,
it could be confusing. If we're going to add features to elog.c to
support this specific case, what I'd rather have is

DETAIL: Process A waits for ...
Process B waits for ...
Process A: <query text>
Process B: <query text>

where the second group of lines only appears in the server log.

> If we add that, perhaps we could clean up the stuff in
> checkSharedDependency with it, too.

Hmm, hadn't realized there were other use-cases already. That makes me
a little more willing to spend effort here. Not sure that the above
design quite works for pg_shdepend though. Do we need two independent
strings for client and log details?

regards, tom lane