Gregory Stark <stark@enterprisedb.com> writes:
> The real problem is that we don't have, and don't particularly want, a memory
> manager for the shared memory.
No, the real problem is that you can't re-size a SysV shared memory
segment on the fly --- there's no portable API for that, anyway.
Therefore there's not much point in having dynamic memory management
within the segment: you pretty much have to predetermine the total size
of each structure you want to have in shared memory, so that you know
what size segment to create in the first place.
I'm of the opinion that the solution to FSM being fixed-size is to keep
it somewhere else, ie, on disk (possibly with some sort of cache in
shared memory for currently-used entries).
regards, tom lane