For my part, I don't see any current need for extra locking here. Veil ensures that only one session ever calls LWLockAssign(), and as the Veil LWLock is allocated on the first piece of user-invoked SQL to call a Veil function, I see no scope for races between Veil and the rest of Postgres.
Maybe the correct thing to do is only allow 1 user-defined LWLock for now, and place a comment with the definition of NUM_USER_DEFINED_LWLOCKS to warn that locking should be implemented if more than 1 is ever needed. __ Marc On Fri, 2005-10-07 at 16:21 -0400, Tom Lane wrote: > Marc Munro <[EMAIL PROTECTED]> writes: > > On the use of LWLockAssign():can anyone tell me if I should protect the > > call using the ShmemLock spinlock? > > Hmm ... the comment for LWLockAssign is not meant to imply that the > caller could do that; in the event of being out of LWLocks, the code > would elog(FATAL) without releasing the spinlock, which would lock up > the whole database. If we were to do it that way we'd need the spinlock > handling to be done inside LWLockAssign. This would not be that bad, > just a marginal slowdown during database startup, but given the low > demand for this feature I'm not very eager to do it. > > The alternative though would seem to be to adopt some convention about > another LWLock to take while trying to assign a new LWLock post-startup. > None of the existing locks seem very appropriate for this, and putting > the responsibility on callers might be unwise anyway. > > Thoughts? > > regards, tom lane
signature.asc
Description: This is a digitally signed message part
