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>,Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,PostgreSQL Win32 port list <pgsql-hackers-win32(at)postgresql(dot)org>
Subject: Re: fork/exec
Date: 2003-12-01 00:37:23
Message-ID: A02DEC4D1073D611BAE8525405FCCE2B028056@harris.memetrics.local (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers-win32

> Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)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?


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: Tom LaneDate: 2003-12-01 01:55:35
Subject: Re: fork/exec
Previous:From: Tom LaneDate: 2003-11-30 17:30:11
Subject: Re: fork/exec

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