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 <marc@bloodnok.com> 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