> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Agreed. We have to pass the shared memory address, but the
> rest should
> > be registered in shared memory somewhere and we can initialize those
> > values. The old code used to point _using_ those memory
> pointers, but I
> > don't think that is necessary --- in fork/exec mode, we can just use
> > share memory to initialize the pointers properly.
>
> Yeah. It might be useful to extend the shmem segment header (which at
> the moment is mostly just for identification) to hold one or two
> critical addresses, such as the address of the LWLock array. But the
> index map used to work for this back when we had fork/exec in the Unix
> implementation, so it should be possible to make it work again without
> undue amounts of pain.
>
> regards, tom lane
Understood.
One slight circular problem with that. Currently, ShmemInitStruct waits on a
lock (ShmemIndexLock), locks require the MyProc structure (set by
InitProcess), and InitProcess needs access to... a bunch of shared memory
structs :-)
Would it be possible to re-jig ShmemInitStruct to not require locking (at
least for backend initialization)? Other ideas?
Cheers,
Claudio
---
Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see
<a
href="http://www.memetrics.com/emailpolicy.html">http://www.memetrics.com/em
ailpolicy.html</a>
