Marc Munro <[EMAIL PROTECTED]> writes:
> Thanks for this. I am very happy that this patch will be going in.
> Thanks also for pointing out the correct header to use.
Patch applied for 8.1.
> 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.
Yeah, MMCacheLock is for long-dead code, so you can probably get away
with using it in the back versions.
> 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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
