Re: fork/exec
От
Claudio Natoli
Тема
Re: fork/exec
Дата
Msg-id
A02DEC4D1073D611BAE8525405FCCE2B028053@harris.memetrics.local
Список
Дерево обсуждения
Re: fork/exec Claudio Natoli <claudio.natoli@memetrics.com>
Re: fork/exec Bruce Momjian <pgman@candle.pha.pa.us>
Re: fork/exec Tom Lane <tgl@sss.pgh.pa.us>
> Bruce Momjian 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 http://www.memetrics.com/em ailpolicy.html
В списке pgsql-hackers-win32 по дате отправления