Re: pg_shmem_allocations view
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael.paquier@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@2ndquadrant.com>, Marti Raudsepp <marti@juffo.org>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2016-05-05T23:01:40Z
Lists: pgsql-hackers
Attachments
On 2014-09-19 23:07:07 -0500, Michael Paquier wrote: > On Mon, Aug 18, 2014 at 1:12 PM, Robert Haas <robertmhaas@gmail.com> wrote: > > On Mon, Aug 18, 2014 at 1:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> Robert Haas <robertmhaas@gmail.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. Here's a rebased version. I remember why I didn't call the column "offset" (as Michael complained about upthread), it's a keyword... Regards, Andres
Commits
-
Add pg_shmem_allocations view.
- ed10f32e37e9 13.0 landed