Horton

Re: Creating a function for exposing memory usage of backend process

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: torikoshia <torikoshia@oss.nttdata.com>
Cc: Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>, Andres Freund <andres@anarazel.de>, Fujii Masao <masao.fujii@oss.nttdata.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-07-31T19:23:52Z
Lists: pgsql-hackers 
On Fri, Jul 31, 2020 at 4:25 AM torikoshia <torikoshia@oss.nttdata.com> wrote:
> And as Fujii-san told me in person, exposing memory address seems
> not preferable considering there are security techniques like
> address space layout randomization.

Yeah, exactly. ASLR wouldn't do anything to improve security if there
were no other security bugs, but there are, and some of those bugs are
harder to exploit if you don't know the precise memory addresses of
certain data structures. Similarly, exposing the addresses of our
internal data structures is harmless if we have no other security
bugs, but if we do, it might make those bugs easier to exploit. I
don't think this information is useful enough to justify taking that
risk.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Add regression test for pg_backend_memory_contexts.

  2. Move codes for pg_backend_memory_contexts from mmgr/mcxt.c to adt/mcxtfuncs.c.

  3. Prevent non-superusers from reading pg_backend_memory_contexts, by default.

  4. Add pg_backend_memory_contexts system view.

  5. Fix yet another issue with step generation in partition pruning.