Re: [HACKERS] pg_shmem_allocations view

At Mon, 30 Dec 2019 13:52:50 -0500, Robert Haas <robertmhaas(at)gmail(dot)com> wrote in
> 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."

Ugh.. Thanks for the explanation and I'm convinced that the current
wording is the best.

> > > 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.

Sorry for the strange sentense. "I agree to (2)" meant that "I agree
that (2) is done in later patch".

About (1), I perplexed by the word "hole", which seemed to me as a
region that is not allocated to anything. But no columns with the
name actually is not in the view, so the view is not wrong in the
first place.

I agree to the patch as-is. Thanks for the explanatin.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center