Re: pg_shmem_allocations view

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_shmem_allocations view
Date: 2014-09-20 04:07:07
Message-ID: CAB7nPqSYXgmDAOVvpw9f=LtTbPDXX4rQEOoV2yHe+8gLOKsm7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 18, 2014 at 1:12 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Mon, Aug 18, 2014 at 1:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2014-09-20 04:16:28 Re: Support for N synchronous standby servers
Previous Message Michael Paquier 2014-09-20 04:02:42 Re: Add CREATE support to event triggers