Re: fork/exec patch
От | Neil Conway |
---|---|
Тема | Re: fork/exec patch |
Дата | |
Msg-id | 87llpd2olw.fsf@mailbox.samurai.com обсуждение исходный текст |
Ответ на | Re: fork/exec patch (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: fork/exec patch
|
Список | 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 по дате отправления: