Re: pg_shmem_allocations view

On Wed, May 7, 2014 at 5:54 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-05-07 17:48:15 -0400, Robert Haas wrote:
>> On Tue, May 6, 2014 at 6:09 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> >> 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?
>>
>> Yeah, that seems all right.
>
> Hm. Not sure what you're ACKing here ;).

The idea of giving the unallocated memory a NULL key.

>> One way to avoid conflict with an actual segment would be to add an
>> after-the-fact entry into ShmemIndex representing the amount of memory
>> that was used to bootstrap it.
>
> There's lots of allocations from shmem that cannot be associated with
> any index entry though. Not just ShmemIndex's own entry. Most
> prominently most of the memory used for SharedBufHash isn't actually
> associated with the "Shared Buffer Lookup Table" entry - imo a
> dynahash.c defficiency.

Hmm, I don't know what to do about that.

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