Re: Use a signal to trigger a memory context dump?

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Use a signal to trigger a memory context dump?
Date: 2014-06-23 12:36:02
Message-ID: 20140623123602.GG16098@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres,

* Andres Freund (andres(at)2ndquadrant(dot)com) wrote:
> I wonder if it'd make sense to allow a signal to trigger a memory
> context dump? I and others more than once had the need to examine memory
> usage on production systems and using gdb isn't always realistic.

+100

I keep thinking we have this and then keep being disappointed when I go
try to find it.

> I wonder if we could install a signal handler for some unused signal
> (e.g. SIGPWR) to dump memory.

Interesting thought, but..

> I'd also considered adding a SQL function that uses the SIGUSR1 signal
> multiplexing for the purpose but that's not necessarily nice if you have
> to investigate while SQL access isn't yet possible. There's also the
> problem that not all possibly interesting processes use the sigusr1
> signal multiplexing.

I'd tend to think this would be sufficient. You're suggesting a case
where you need to debug prior to SQL access (not specifically sure what
you mean by that) or processes which are hopefully less likely to have
memory issues, but you don't have gdb..

Another thought along the lines of getting information about running
processes would be to see the call stack or execution plan.. I seem to
recall there being a patch for the latter at one point?

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2014-06-23 12:36:43 Re: pgaudit - an auditing extension for PostgreSQL
Previous Message Nicholas White 2014-06-23 12:27:41 Re: Request for Patch Feedback: Lag & Lead Window Functions Can Ignore Nulls