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
-
Add pg_shmem_allocations view.
- ed10f32e37e9 13.0 landed