Re: pg_shmem_allocations view - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pg_shmem_allocations view
Date
Msg-id 20160505230140.dbzcvlzip7pqbgxe@alap3.anarazel.de
Whole thread Raw
In response to Re: pg_shmem_allocations view  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: pg_shmem_allocations view  (Michael Paquier <michael.paquier@gmail.com>)
Re: [HACKERS] pg_shmem_allocations view  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
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

Attachment

pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: pg9.6 segfault using simple query (related to use fk for join estimates)
Next
From: Tom Lane
Date:
Subject: Re: Naming of new tsvector functions