Paul van den Bogaard wrote:
> Since these data structures are for collecting information I was able to
> create a new function that retrieves its information from these data
> structures and returns them as a result from a query.
>
> However this is too intrusive. Since everything is in shared memory it
> should be possible for an external, yet to be created, process to attach
> to the shared memory segment (read only mode only) to collect these data
> structures.
That sounds dangerous. I'm seeing problems with postmaster stop and
restart if there's an external process attached to the postgres shared
memory segment.
> I have the address mapping of the shared memory (doing stuff on Solaris
> only). I can pass this information to InitShmemAccess (ipc/shmem.c).
> There is however a missing settting for ShmemIndex. This one can be
> initialsed by calling InitShmemIndex(). The only thing that makes me
> wonder is its need to use ShmemIndexLock. Although this is just an enum,
> and therefore an index in some array created in CreateLWLock
> (lwlock.c). I do not see how I can get access to this lock.
You can't acquire a lightweight lock safely outside a real backend.
You'd need to have a valid PGPROC entry, at least.
I would suggest forgetting about that idea and sticking to your original
approach of a function that returns the data as a result from a query.
Or, create a completely separate shared memory block for your own data,
using plain Solaris shmem functions.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
