> 1. Change memory context to TopMemoryContext and palloc everything there.
> (However, I believe this still isn't shared between processes?)
> 2. Use the shmem functions in src/backend/storage/ipc/shmem.c to create a
> chunk of shared memory and use this (Although I would like to avoid writing
> my own memory manager to carve up the space).
> 3. Somehow create shared memory using the shmem functions, and set a memory
> context to live *inside* this shared memory, which my trigger functions can
> then switch to. Then use palloc() and pfree() without worrying..
You'd have to do one of the above, but #2 is probably out because all
shared memory is allocated to various purposes at startup and there is
none free at runtime (as I understand it).
For #3, how do you plan to have a memory context shared by multiple
backends with no synchronization? If two backends try to do
allocation or deallocation at the same time you will get corruption,
as I don't think palloc() and pfree() do any locking (they currently
never allocate from shared memory).
You should probably think very carefully about whether you can get
along without using additional shared memory, because it's not that
easy to do.
In response to
pgsql-hackers by date
|Next:||From: Richard Hills||Date: 2006-02-05 14:31:23|
|Subject: Re: Shared memory and memory context question|
|Previous:||From: Magnus Hagander||Date: 2006-02-05 14:15:58|
|Subject: Re: [PATCHES] Fix for running from admin account on win32|