Re: fork/exec patch - Mailing list pgsql-patches

From Neil Conway
Subject Re: fork/exec patch
Date
Msg-id 87llpd2olw.fsf@mailbox.samurai.com
Whole thread Raw
In response to Re: fork/exec patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: fork/exec patch
List pgsql-patches
Tom Lane <tgl@sss.pgh.pa.us> writes:
> That one I can answer --- it's a bootstrapping issue: we can't use
> LWLocks until we have a PGProc (*MyProc), and we can't set that up
> without looking in the ShmemIndex for the related data structures.
> So ShmemIndex needs to use a more primitive lock type.

Fair enough.

My next question would have been to ask whether switching to a
spinlock here will be a performance problem. In looking at the code,
it seems we only hold the ShmemIndexLock for a long time (hundreds of
instructions & multiple system calls) while bootstrapping the shmem
index hash table itself. Otherwise, the lock is acquired and released
quickly, and even then it is only done during backend initialization,
so there shouldn't be much contention for it. Is this analysis
correct?

> I don't want to make these things public, because we don't really
> want any other modules accessing them.

I agree, both ways are non-optimal for different reasons. Can anyone
else see a better way to do this?

-Neil


pgsql-patches by date:

Previous
From: Claudio Natoli
Date:
Subject: Re: fork/exec patch
Next
From: Neil Conway
Date:
Subject: Re: fork/exec patch