>>ShmZoneContext for SharedPlan and SharedRelCache is not implemented but >>I'm going to do it following your points. > >After looking into existing code, I'm thinking Generation Memory Context seems >to >have the similar purpose. So I'll implement ShmZoneContext by reference it. >Generation context manages chunks having almost same life span. >ShmZoneContext would dsa_allocate() block and hand out chunks and free chunks >and >its block all together.
I added ShmZoneContext to my patch. I haven't added detailed comments and test set, so let me explain how to use it here. I followed Thomas' suggestion. At start up, ShmZoneContext is created in shared memory by ShmZoneContextCreateOrigin(). Before allocating memory, another context is created and set to short-lived parent context via MemoryContextClone() so that objects and contexts are automatically freed. Then you can use, palloc() which returns chunk from dsa_allocated block. When you use MemoryContextSetParent() to long-lived ShmContext, you need to acquire lock to protect parent-child path. The LWLock object is get by ShmZoneContextGetLock(). Every cloned ShmZoneContext uses the same lock instance. If you want to free allocated object, use MemoryContextDelete(). After the context becomes long-lived, you need to get lock again to do MemoryContextDelete() in order to protect MemoryContext parent-child path. Thinking about use case of Shared RelCache/PlanCache, allocation happens only before the parent context is switch to long-lived shared one, so I think we don't need to take lock while palloc(). I also think MemoryContextDelete() should be done after allocated objects are deleted from some shared index structure (ex. hash table or list in shared memory) so that another process can take a look at it What do you think? Regards, Takeshi Ideriha
shm_zone_retail_context-v2.patch
Description: shm_zone_retail_context-v2.patch
