On Sun, May 4, 2014 at 7:50 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> On 2014-05-04 13:44:17 +0200, Andres Freund wrote:
>> postgres=# SELECT * FROM pg_shmem_allocations ORDER BY size DESC;
>> key | off | size | allocated
>> -------------------------------------+-------------+-------------+-----------
>> Buffer Blocks | 286242528 | 17179869184 | t
>> Buffer Descriptors | 152024800 | 134217728 | t
>> ...
>> OldSerXidControlData | 17584357344 | 16 | t
>> (44 rows)
>
> Thinking about this, I think it was a mistake to not add a 'name' field
> to dynamic shared memory's dsm_control_item. Right now it's very hard to
> figure out which extension allocated a dsm segment. Imo we should change
> that before 9.4 is out. I am not suggesting to use it to identify
> segments, but just as an identifier, passed in into dsm_create().
>
> Imo there should be a corresponding pg_dynshmem_allocations to
> pg_shmem_allocations.
Well, right now a dsm_control_item is 8 bytes. If we add a name field
of our usual 64 bytes, they'll each be 9 times bigger. We're not
talking about a lot of bytes in absolute terms, but I guess I'm not in
favor of an 800% size increase without somewhat more justification
than you've provided here. Who is using dynamic shared memory for
enough different things at this point to get confused?
I'm quite in favor of having something like this for the main shared
memory segment, but I think that's 9.5 material at this point.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company