Re: Using ProcSignal to get memory context stats from a running backend

From: Greg Stark <stark(at)mit(dot)edu>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Using ProcSignal to get memory context stats from a running backend
Date: 2017-12-15 01:24:08
Message-ID: CAM-w4HN1LBkn=eWhXm21MfDEmu=HSidNn7WS5ehNAYk=OcAi1Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Another simpler option would be to open up a new file in the log
directory something like "debug_dump.<pid>.txt" and print whatever you
want there. Then print out a reasonable size log entry saying "Debug
dump output to file 'debug_dump.<pid>.txt'". You could provide a
function that reads such files out of the log directory or just
document how to access them using the pg_read_file().

It's not perfect but it's got most of the advantages of communicating
with the requesting process without the complexities of a DSM segment
and it's a bit more flexible too. Users can have automated monitoring
tools watch for dumps for example. And regular tools can be used to
back up and clean out old files.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jordan Deitch 2017-12-15 01:37:46 pearltidy source code has been removed (pgindent)
Previous Message Thomas Munro 2017-12-15 01:12:29 Re: Top-N sorts verses parallelism