Re: [HACKERS] pg_shmem_allocations view

On Wed, Dec 18, 2019 at 9:53 PM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
> The doc is saying that "size" is "Size of the allocation" and
> "allocated_size" is "size including padding". It seems somewhat
> confusing to me. I'm not sure what wording is best but I think people
> use net/gross wordings to describe like that.

I don't think I'd find that particularly clear. It seems to me that if
the second size includes padding, then the first one differs in not
including padding, so I'm not really sure where the confusion is. I
thought about writing, for the first one, that is the requested size
of the allocation, but that seemed like it might confuse someone by
suggesting that the actual size of the allocation might be less than
what was requested. I also thought about describing the first one as
the size excluding padding, but that seems redundant. Maybe it would
be good to change the second one to say "Size of the allocation
including padding added by the allocator itself."

> > All of this makes me think that we might want to do some followup to
> > (1) convert anonymous allocations to non-anonymous allocations, for
> > inspectability, and (2) do some renaming to get better stylistic
> > agreement between the names of various shared memory chunks. But I
> > think that work is properly done after this patch is committed, not
> > before.
>
> I agree to (2), but regarding (1), most or perhaps all of the
> anonymous allocations seems belonging to one of the shared hashes but
> are recognized as holes shown by the above statement. So the current
> output of the view is wrong in that sense. I think (1) should be
> resolved before adding the view.

I guess I don't understand how this makes the output wrong. Either the
allocations have a name, or they are anonymous. This dumps everything
that has a name. What would you suggest? It seems to me that it's more
appropriate for this patch to just tell us about what's in shared
memory, not change what's in shared memory. If we want to do the
latter, that's a job for another patch.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company