I was looking at
https://www.postgresql.org/message-id/CAG_=8kAYKjhQX3FmAWQBC95Evh3+qszOQxkNMm1Q4W1QO7+c4Q@mail.gmail.com
in which the most salient issue is
> 2018-03-28 19:20:33.264 UTC [10580] cory@match ERROR: out of memory
> 2018-03-28 19:20:33.264 UTC [10580] cory@match DETAIL: Failed on request of size 1610612736.
and it suddenly struck me that this'd be noticeably more useful, at least
for experts, if the errdetail included the name of the memory context
we were trying to allocate in. In this case it'd be nice to know right
off the bat whether the failure occurred in MessageContext, which looked
bloated already, or someplace else.
In the wake of commit 442accc3f one might think that the message should
also include the context "identifier" if any. But I'm specifically not
proposing that, because of the point made in the discussion of that patch
that some identifier strings might contain security-sensitive query
excerpts. Now that that commit has required all context "names" to be
compile-time constants, it's hard to see how there could be any security
downside to showing them in a user-visible message.
Of course, by the same token, maybe this change wouldn't be as useful
as I'm thinking. But I can think of past cases where being able to
distinguish, say, allocation failures in a query's global ExecutorState
versus ones in an ExprState would save some effort.
Thoughts?
regards, tom lane
