Re: pg_shmem_allocations view

On 2014-05-06 15:37:04 -0400, Robert Haas wrote:
> On Tue, May 6, 2014 at 2:34 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> >> Attached are two patches:
> >> a) Patch addin a 'name' parameter to dsm_create(). I think we should
> >> apply this to 9.4.
> >> b) pg_dynamic_shmem_allocations and pg_static_shmem_allocations
> >> views. The previous version didn't include dsm support and didn't
> >> take the required lock.
> >
> >> I am not so sure whether b) should be applied together with a) in 9.4,
> >> but I'd be happy enough to add docs if people agree with the naming.
> >
> > FWIW, I vote for fixing (a) now but holding (b) for 9.5.
>
> I guess I'll vote for applying both. I don't see a lot of risk, and I
> think doing one with out the other is somewhat pointless.

Fine with me. I guess if we don't do b) for now we can just do the
additional parameter and the Assert() from the patch. Without actually
storing the name to shared memory.

> Regarding patch 0002, I don't think we're using the term "static
> shmem" anywhere else, so I vote for dropping the word static, so that
> we have pg_get_shmem_allocations() and
> pg_get_dynamic_shmem_allocations().

Fine #2.

> Also, I think using the
> "allocated" column is pretty weird. There are always exactly two
> entries with allocated = false

Hm. There shouldn't be. And at least in my installation there isn't and
I don't see a anything in the code that'd allow that? The example from
my last email has:

> postgres=# SELECT * FROM pg_static_shmem_allocations ORDER BY key NULLS FIRST;
> key | off | size | allocated
> -------------------------------------+------------+------------+-----------
> | 2222605024 | 1727776 | f
> | | 34844752 | t
> Async Ctl | 2222539168 | 65856 | t

>, one of which is for actual free memory
> and the other of which is for memory that actually IS allocated but
> without using ShmemIndex (maybe the latter was supposed to have
> allocated = true but still key = null?).

Yes, that's how I'd imagined it.

> I guess I'd vote for
> ditching the allocated column completely and outputting the memory
> allocated without ShmemIndex using some fixed tag (like "ShmemIndex"
> or "Bootstrap" or "Overhead" or something).

My way feels slightly cleaner, but I'd be ok with that as well. There's
no possible conflicts with an actual segment... In your variant the
unallocated/slop memory would continue to have a NULL key?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services