>>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