From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "Paul van den Bogaard" <Paul(dot)Vandenbogaard(at)Sun(dot)COM> |
Cc: | "PostgreSQL-development list" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Attaching and using the Postgres shared memory segment |
Date: | 2008-07-03 11:33:01 |
Message-ID: | 486CB8ED.8080703@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-07-03 12:34:05 | Re: Resolving polymorphic functions with related datatypes |
Previous Message | Heikki Linnakangas | 2008-07-03 11:11:34 | Re: Resolving polymorphic functions with related datatypes |