Thread: Re: fork/exec

> 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>

Claudio Natoli wrote:
> 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?

At the time the postmaster is to populate that area, there is on one
else running, so you don't need locking, and the backends are going to
only be reading that area, so I don't think they need a lock.  Of
course, you might need to put all that stuff at the start of shared
memory so the backends know where to find it.

--
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Would it be possible to re-jig ShmemInitStruct to not require locking

That strikes me as entirely unsafe.

Back when we actually had fork/exec for Unix, there were three shmem
segments not one.  Part of the reason for this was that spinlocks
occupied their own segment, and so they could be found and accessed
without any reference to the main shmem index.  (I forget what the
third segment was for, but I think it was not critical for startup.)

Probably the best way to model this now is to put a pointer (or whatever
is needed) to the LWLock array into the shmem segment header, whence
it can be grabbed without any locking.  This will allow a new backend's
lock manager to be initialized immediately.  Then we can safely (ie,
with locking) initialize access to the shmem index hashtable (it might
take another pointer in the segment header to find it) and then
everything else can be looked up in the index hashtable.

            regards, tom lane