Horton

Re: Get memory contexts of an arbitrary backend process

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>
Cc: torikoshia <torikoshia@oss.nttdata.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-09-24T04:01:49Z
Lists: pgsql-hackers 
On Thu, Sep 10, 2020 at 09:11:21PM +0900, Kasahara Tatsuhito wrote:
> I think it's fine to have an interface to delete in an emergency, but
> I agree that
> users shouldn't be made aware of the existence or deletion of dump
> files, basically.

Per the CF bot, the number of tests needs to be tweaked, because we
test each entry filtered out with is_deeply(), meaning that the number
of tests needs to be updated to reflect that if the filtered list is
changed:
t/010_pg_basebackup.pl ... 104/109 # Looks like you planned 109 tests but ran 110.
t/010_pg_basebackup.pl ... Dubious, test returned 255 (wstat 65280, 0xff00)
All 109 subtests passed

Simple enough to fix.
--
Michael

Commits

  1. Add function to log the memory contexts of specified backend process.

  2. Add pg_backend_memory_contexts system view.

  3. Limit the verbosity of memory context statistics dumps.