Обсуждение: Attaching and using the Postgres shared memory segment

to look into an idea I currently have I need (and implemented)  a new  
piece of memory that resides in (Postgres) shared memory.  My data  
structures are in place an the new database seems running fine. Even  
under high load :-)

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.

However, when I read the source I feel a little stuck. Kind of chicken  
and egg situation perhaps.

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. Is it "just" there since obviously the whole Postgres shared  
memory is allocated, initialised and likely already heavily used.
Do the locks map to a "well know address" so I can do without further  
in process initialisation? Or is there another routine (or two ...)  
that I need to call in order to make things working.

Advise on how to proceed or pointers to docs in which this stuff is  
explained are highly appreciated.

Thanks
Paul.



---------------------------------------------------------------------------------------------
Paul van den Bogaard                               Paul.vandenBogaard@sun.com
ISV-E  -- ISV Engineering, Opensource Engineering group

Sun Microsystems, Inc                              phone:        +31  
334 515 918
Saturnus 1                                                 extentsion:  
x (70)15918
3824 ME Amersfoort                                 mobile:       +31  
651 913 354
The Netherlands                                        fax:             
+31 334 515 001

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