Re: Shared memory and memory context question

On Sun February 5 2006 14:11, Martijn van Oosterhout wrote:
> This is the generally accepted method. Please remember that when
> sharing structures you have to worry about concurrency. So you need
> locking.

Of course - I have already implemented locking with semaphores (I may simply
use one big lock and carefully avoid reentry).

> Nope, palloc/pfree don't deal with concurrency.

Indeed, although if I lock the shared memory then I can palloc and pfree()
without worrying. The problem I see is that new memory contexts have their
memory assigned to them when they are created. I can't tell them "go here!"

> Most people allocate chunks of shared memory and don't use
> palloc/pfree. What are you doing that requires such management? Most
> shared structures in PostgreSQL are allocated once and never freed...

I have a number of functions which modify tables based on complex rules stored
in script-files. I wrote a parser for these files as a separate program first
before incorporating it as a shared object, subsequentially it loads and
executes rules from memory. As anything can be read from the files, and rules
can be unloaded later, I was hoping for flexibility in allocing memory to
store it all.

Another option is to load the files but store the rules within the database,
which should be possible, but appears to be a slightly messy way of doing it.
Then again, messing about with shared memory allocation may be messier.
Asking as an fairly inexperienced postgres person, what would you suggest?