| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Using ProcSignal to get memory context stats from a running backend |
| Date: | 2017-12-21 07:24:07 |
| Message-ID: | 20171221072407.z2iymwxl7o3gji6z@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2017-12-21 15:13:13 +0800, Craig Ringer wrote:
> There tons of callers to enlargeStringInfo, so a 'noerror' parameter would
> be viable.
Not sure what you mean with that sentence?
> But I'm not convinced it's worth it personally. If we OOM in response to a
> ProcSignal request for memory context output, we're having pretty bad luck.
> The output is 8k in my test. But even if it were a couple of hundred kb,
> happening to hit OOM just then isn't great luck on modern systems with many
> gigabytes of RAM.
I've seen plenty memory dumps in the dozens to hundreds of
megabytes. And imo such cases are more likely to invite use of this
facility.
> If that *does* happen, repalloc(...) will call
> MemoryContextStats(TopMemoryContext) before returning NULL. So we'll get
> our memory context dump anyway, albeit to stderr.
That would still abort the query that might otherwise continue to work,
so that seems no excuse.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Craig Ringer | 2017-12-21 07:55:35 | Re: Using ProcSignal to get memory context stats from a running backend |
| Previous Message | Craig Ringer | 2017-12-21 07:20:20 | The pg_indent on on ftp is outdated |