Re: pg_shmem_allocations view

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_shmem_allocations view
Date: 2014-05-07 21:48:15
Message-ID: CA+TgmoY7QYZfSXGyc=jXv8nO85vX7XzqqYYh7tUejVd6Cxmyew@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-05-07 21:51:24 Re: proposal: Set effective_cache_size to greater of .conf value, shared_buffers
Previous Message Robert Haas 2014-05-07 21:45:38 Re: bgworker crashed or not?