From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Claudio Natoli <claudio(dot)natoli(at)memetrics(dot)com>, "'pgsql-patches(at)postgresql(dot)org'" <pgsql-patches(at)postgresql(dot)org> |
Subject: | Re: fork/exec patch |
Date: | 2003-12-16 07:44:43 |
Message-ID: | 87llpd2olw.fsf@mailbox.samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-hackers-win32 pgsql-patches |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2003-12-16 08:23:03 | Re: 7.4 include file conflict |
Previous Message | Tom Lane | 2003-12-16 05:11:04 | Re: fork/exec patch |
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2003-12-16 08:13:46 | Re: Build error in src/interfaces |
Previous Message | Tom Lane | 2003-12-16 05:11:04 | Re: fork/exec patch |
From | Date | Subject | |
---|---|---|---|
Next Message | Neil Conway | 2003-12-16 08:07:56 | Re: fork/exec patch |
Previous Message | Claudio Natoli | 2003-12-16 07:31:20 | Re: fork/exec patch |