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
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 cont
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
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 Lane wrote:
> Bruce Momjian 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 yo
Bruce Momjian 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? The proposed defau
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 entries in pg_config_
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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
lwlock.h). However, it
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 m
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 th
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)
This is to announce the first, Alpha, release of Veil, a database
security add-on for Postgres. It allows databases to be created with
efficient row-level access controls; different users have access to
different subsets of data.
Veil is hosted on pgfoundry at http://veil.projects.postgresql.org/
14 matches
Mail list logo