Skip site navigation (1) Skip section navigation (2)

Re: fork/exec

From: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
To: 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: fork/exec
Date: 2003-11-30 13:01:07
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B028053@harris.memetrics.local (view raw or whole thread)
Lists: pgsql-hackers-win32
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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


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?


Certain disclaimers and policies apply to all email sent from Memetrics.
For the full text of these disclaimers and policies see 


pgsql-hackers-win32 by date

Next:From: Claudio NatoliDate: 2003-11-30 13:11:54
Subject: Re: fork/exec
Previous:From: Bruce MomjianDate: 2003-11-30 03:31:03
Subject: Re: SRA Win32 sync() code

Privacy Policy | About PostgreSQL
Copyright © 1996-2015 The PostgreSQL Global Development Group