Re: pg_shmem_allocations view
| От | Robert Haas |
|---|---|
| Тема | Re: pg_shmem_allocations view |
| Дата | |
| Msg-id | CA+TgmoY+zPmbbyToJfgsqq8P9r=qBC7zsnzvXL355e5KkEJcZg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_shmem_allocations view (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: pg_shmem_allocations view
|
| Список | 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
В списке pgsql-hackers по дате отправления: