From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(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-08-18 16:27:12 |
Message-ID: | 4378.1408379232@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2014-08-18 11:56:44 -0400, Robert Haas wrote:
>> 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.
> Meh. For one it's just the offsets, not the actual addresses. It's also
> something you can relatively easily compute at home by looking at a
> couple of settings everyone can see. For another, I'd be perfectly
> content making this superuser only. And if somebody can execute queries
> as superuser, address layout information really isn't needed anymore to
> execute arbitrary code.
I agree that this has to be superuser-only if it's there at all.
Should we consider putting it into an extension rather than having
it in the core system? That would offer some additional protection
for production systems, which really shouldn't have much need for
this IMO.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2014-08-18 16:30:23 | Re: pg_shmem_allocations view |
Previous Message | Robert Haas | 2014-08-18 16:23:02 | Re: Support for N synchronous standby servers |