On 2014-05-07 17:48:15 -0400, Robert Haas wrote: > On Tue, May 6, 2014 at 6:09 PM, Andres Freund <and...@2ndquadrant.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 ;). > 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. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
