Re: pg_shmem_allocations view - Mailing list pgsql-hackers

On 2014-05-06 15:37:04 -0400, Robert Haas wrote:
> On Tue, May 6, 2014 at 2:34 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Andres Freund <andres@2ndquadrant.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