On Sun, May 4, 2014 at 7:50 AM, Andres Freund <and...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
