Small proposal to improve out-of-memory messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Small proposal to improve out-of-memory messages
Date: 2018-03-29 01:07:08
Message-ID: 1099.1522285628@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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(at)match ERROR: out of memory
> 2018-03-28 19:20:33.264 UTC [10580] cory(at)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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2018-03-29 01:27:55 Re: ALTER TABLE ADD COLUMN fast default
Previous Message Michael Paquier 2018-03-29 01:03:28 Re: Changing WAL Header to reduce contention during ReserveXLogInsertLocation()