Re: pg_shmem_allocations view - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: pg_shmem_allocations view
Date
Msg-id CAB7nPqSYXgmDAOVvpw9f=LtTbPDXX4rQEOoV2yHe+8gLOKsm7A@mail.gmail.com
Whole thread Raw
In response to Re: pg_shmem_allocations view  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pg_shmem_allocations view  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On Mon, Aug 18, 2014 at 1:12 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Aug 18, 2014 at 1:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> I thought you were printing actual pointer addresses.  If you're just
>>> printing offsets relative to wherever the segment happens to be
>>> mapped, I don't care about that.
>>
>> Well, that just means that it's not an *obvious* security risk.
>>
>> I still like the idea of providing something comparable to
>> MemoryContextStats, rather than creating a SQL interface.  The problem
>> with a SQL interface is you can't interrogate it unless (1) you are not
>> already inside a query and (2) the client is interactive and under your
>> control.  Something you can call easily from gdb is likely to be much
>> more useful in practice.
>
> Since the shared memory segment isn't changing at runtime, I don't see
> this as being a big problem.  It could possibly be an issue for
> dynamic shared memory segments, though.
Patch has been reviewed some time ago, extra ideas as well as
potential security risks discussed as well but no new version has been
sent, hence marking it as returned with feedback.
-- 
Michael



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Add CREATE support to event triggers
Next
From: Michael Paquier
Date:
Subject: Re: Support for N synchronous standby servers