Re: fork/exec

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: 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-11-30 17:30:11
Message-ID: 24103.1070213411@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

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

In response to

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Claudio Natoli 2003-12-01 00:37:23 Re: fork/exec
Previous Message Bruce Momjian 2003-11-30 15:48:45 Re: fork/exec