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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
