Small proposal to improve out-of-memory messages
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2018-03-29T01:07:08Z
Lists: pgsql-hackers
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
Commits
-
Improve out-of-memory error reports by including memory context name.
- 1bb9e731e17b 11.0 landed
-
Allow memory contexts to have both fixed and variable ident strings.
- 442accc3fe0c 11.0 cited