From: | Marc Munro <marc(at)bloodnok(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: User-assigned LWLocks (was Re: Announcing Veil) |
Date: | 2005-10-10 00:00:34 |
Message-ID: | 1128902435.18452.15.camel@bloodnok.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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(at)bloodnok(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-10-10 01:21:08 | Re: fixing LISTEN/NOTIFY |
Previous Message | Josh Berkus | 2005-10-09 20:04:05 | Re: fixing LISTEN/NOTIFY |