In response to both Bruce and Tom, Thanks for this. I am very happy that this patch will be going in. Thanks also for pointing out the correct header to use.
As Tom points out, this will do nothing for users of 7.4 and 8.0. For these versions I propose to continue to use MMCacheLock. As far as I can see, this is safe in 7.4, and otherwise unused in 8.0. On the use of LWLockAssign():can anyone tell me if I should protect the call using the ShmemLock spinlock? __ Marc Munro On Fri, 2005-10-07 at 00:10 -0400, Bruce Momjian wrote: > Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > > Tom Lane wrote: > > >> With only one known request for a user-allocate d lock, it's hard to > > >> justify the overhead of a GUC variable. > > > > > True, but are people going to recompile PostgreSQL to use this feature? > > > Seems they would have to. > > > > How you figure that? The proposed default value was 4, which seems > > fine to me, given that the known worldwide demand amounts to 1. > > Oh, so you are going to give him a few slots. I thought we were going > to default to 0 and he was going to have to bump it up to use his > software. That sounds fine to me. >
signature.asc
Description: This is a digitally signed message part
