On Mon, Feb 10, 2014 at 7:17 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> Does it make another problem if dsm_detach() also releases lwlocks
> being allocated on the dsm segment to be released?
> Lwlocks being held is tracked in the held_lwlocks[] array; its length is
> usually 100. In case when dsm_detach() is called towards the segment
> between addr ~ (addr + length), it seems to me an easy job to walk on
> this array to find out lwlocks on the range.
Oh, sure, it could be done. I just don't see the point. If you're
explicitly detaching a shared memory segment while still holding
lwlocks within that segment, your code is seriously buggy. Making
dsm_detach() silently release those locks would probably just be
hiding a bug that you'd really rather find out about.
> Just my rough idea. Doesn't it make sense to have an offset from the
> head of DSM segment that contains the lwlock, instead of the identifier
> form, to indicate a cstring datum? It does not prevent to allocate it
> later; after the postmaster starting up, and here is no problem if number
> of dynamic lwlocks grows millions or more.
> If lwlock has a "tranche_offset", not "tranche_id", all it needs to do is:
> 1. find out either of DSM segment or regular SHM segment that contains
> the supplied lwlock.
> 2. Calculate mapped_address + tranche_offset; that is the local location
> where cstring form is put.
Well, if that offset is 8 bytes, it's going to make the LWLock
structure grow past 32 bytes on common platforms, which I do not want
to do. If it's 4 bytes, sure, that'll work, but now you've gotta make
sure that string gets into the 4GB of the relevant shared memory
segment, which sounds like an annoying requirement. How would you
satisfy it with respect to the main shared memory segment, for
example?
I mean, one way to handle this problem is to put a hash table in the
main shared memory segment with tranche ID -> name mappings. Backends
can suck mappings out of there and cache them locally as needed. But
that's a lot of mechanism for a facility with no known users.
> Probably, it needs a common utility routine on dsm.c to find out
> a particular DSM segment that contains the supplied address.
> (Inverse function towards dsm_segment_address)
Yeah, I've thought of that. It may be useful enough to be worth
doing, whether we use it for this or not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
