On 29 March 2018 at 09:07, Tom Lane <t...@sss.pgh.pa.us> wrote: > I was looking at > https://www.postgresql.org/message-id/CAG_=8kAYKjhQX3FmAWQBC95Evh3+ > qszoqxknmm1q4w1qo7+...@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. > > This would have been significantly useful to me in the past, so +1 from me.
-- Craig Ringer http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
