Thread: Re: fork/exec

Re: fork/exec

From
Claudio Natoli
Date:

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

Well, an implicit assumption in asking if it was "possible" was if it was
possible safely...


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

Agreed. But I think we'd also need to pass ProcGlobal and ProcStructLock,
and move the InitProcess call to be made earlier (so that the MyProc
structure is initialized, which is a requirement for locking). Right?

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>

Re: fork/exec

From
Tom Lane
Date:
Claudio Natoli <claudio.natoli@memetrics.com> writes:
> Agreed. But I think we'd also need to pass ProcGlobal and ProcStructLock,
> and move the InitProcess call to be made earlier (so that the MyProc
> structure is initialized, which is a requirement for locking). Right?

Hm, seems messy.  Note that setting up MyProc does *not* require LWLock
access, only a spinlock (which is obviously necessary to avoid
circularity).  It might be best to replace ShmemIndexLock with a spinlock
to reduce the amount of infrastructure that has to be live before we can
make use of the shmem index hashtable.  I think that ShmemIndexLock *was*
a spinlock originally, and converting it to an LWLock was something that
was done long after we'd abandoned fork/exec.  It seemed like a good
idea at the time, but now I'm wondering.

Bruce is right to note that we are not expecting much contention on
these locks, so changing them to spinlocks shouldn't really create any
performance issues.  I don't want to abandon locking entirely, but I do
think we can simplify the lock type if it helps make the startup
sequence easier.

            regards, tom lane