On Tue, May 6, 2014 at 7:45 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> The control segment is sized to support a number of dynamic shared
>> memory segments not exceeding 64 + 2 *MaxBackends. With default
>> settings, that currently works out to 288 segments, or 2306 bytes.
>> So, adding a 64-byte name to each of those structures would increase
>> the size from 2k to about 20k.
>>
>> So, sure, that's not a lot of memory. But I'm still not convinced
>> that's it's very useful. What I think is going to happen is that (1)
>> most people won't be used dynamic shared memory at all, so they won't
>> have any use for this; (2) those people who do run an extension that
>> uses dynamic shared memory will most likely only be running one such
>> extension, so they won't need a name to know what the segments are
>> being used for; and (3) if and when we eventually get parallel query,
>> dynamic shared memory segments will be widely used, but a bunch of
>> segments that are all named "parallel_query" or "parallel_query.$PID"
>> isn't going to be too informative.
>
> Not sure your arguments hold any water.
I'm not, either.
> Most people don't use most features... and so we're not allowed
> features that can be debugged?
I certainly didn't say that.
> How do you know people will only use one extension that uses dshmem?
I don't. If they do, that's a good argument for adding this.
> Why would we call multiple segments the same thing??
It's not clear to me how someone is going to intelligently name
multiple segments used by the same extension. Maybe they'll give them
all the same name. Maybe they'll name them all extension_name.pid.
More than likely, different extensions will use different conventions.:-(
It might be sensible to add a "creator PID" field to the DSM control
items. Of course, that PID might have exited, but it could still
possibly be useful for debugging purposes.
> If names are a problem, lets give them numbers. Seems a minor point.
> Perhaps we can allocate space for names dynamically??
A static buffer, as proposed by Andres, seems a lot simper.
> Not being able to tell segments apart from each other is just daft, if
> we are trying to supply bug free software for the world to use.
I can see I'm losing this argument.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company