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.
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
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
I don't see NUM_USER_DEFINED_LWLOCKS defined in 8.0 or 8.1, so what
system do you propose to allow you to set this value?
---
Marc Munro wrote:
-- Start of PGP signed section.
Tom,
Thanks for your reponse. Unless I am
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't see NUM_USER_DEFINED_LWLOCKS defined in 8.0 or 8.1, so what
system do you propose to allow you to set this value?
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in pg_config_manual.h not
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
I don't see NUM_USER_DEFINED_LWLOCKS defined in 8.0 or 8.1, so what
system do you propose to allow you to set this value?
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in pg_config_manual.h not
lwlock.h).
Shouldn't it be something we can put in postgresql.conf?
No more than any of the other
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
I'd be willing to add the proposed patch in 8.1 (style note:
NUM_USER_DEFINED_LWLOCKS should be set in pg_config_manual.h not
lwlock.h).
Shouldn't it be something we can put in postgresql.conf?
No more
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
With only one known request for a user-allocated 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?
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Tom Lane wrote:
With only one known request for a user-allocated 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.
On Thu, 2005-06-10 at 23:56 -0400, Bruce Momjian wrote:
True, but are people going to recompile PostgreSQL to use this feature?
Seems they would have to.
They would need to recompile PostgreSQL to use more than the default
number of user-defined LWLocks, which seems perfectly reasonable to me.
Tom,
Thanks for your reponse. Unless I am missing your point, to add more
locks we require a minor code change to the postgres server. I am happy
to submit a patch but this will not help Veil work with existing
versions of Postgres. I am aiming for compatibility with 7.4 onward.
Your views on
Marc Munro [EMAIL PROTECTED] writes:
Since I was unable to dynamically assign a LWLock using
LWLockAssign (none available), I have fairly arbitrarily overloaded the
use of existing LWLocks. When the flames die down perhaps we can
discuss making a small number (one would be enough for me) of
13 matches
Mail list logo
