Re: pg_shmem_allocations view

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Andres Freund <andres@2ndquadrant.com>
Cc: Marti Raudsepp <marti@juffo.org>, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2014-08-18T15:56:44Z
Lists: pgsql-hackers
On Fri, Aug 15, 2014 at 4:20 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-08-15 11:12:11 +0300, Marti Raudsepp wrote:
>> Hi
>> On Thu, May 8, 2014 at 4:28 PM, Andres Freund <andres@2ndquadrant.com> wrote:
>> > Ok. A new version of the patches implementing that are
>> > attached. Including a couple of small fixups and docs. The latter aren't
>> > extensive, but that doesn't seem to be warranted anyway.
>>
>> Is it really actually useful to expose the segment off(set) to users?
>> Seems to me like unnecessary internal details leaking out.
>
> Yes. This is clearly developer oriented and I'd more than once wished I
> could see where some stray pointer is pointing to... That's not really
> possible without something like this.

Unfortunately, that information also has some security implications.
I'm sure someone trying to exploit any future stack-overrun
vulnerability will be very happy to have more rather than less
information about the layout of the process address space.

I fully agree with the idea of exposing the amount of free memory in
the shared memory segment (as discussed in other emails); that's
critical information.  But I think exposing address space layout
information is of much less general utility and, really, far too
risky.

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


Commits

  1. Add pg_shmem_allocations view.