Re: Announcing Veil

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 this would be appreciated.

Assuming that simply allocating a few extra LWLocks for user-defined
functions is acceptable, here are some patches:

--cut---------------
*** ./src/backend/storage/lmgr/lwlock.c Sat Aug 20 16:26:24 2005
--- lwlock.c    Wed Oct  5 08:20:31 2005
***************
*** 120,126 ****        */       numLocks += 2 * NUM_SLRU_BUFFERS;

!       /* Perhaps create a few more for use by user-defined modules? */
       return numLocks; }
--- 120,127 ----        */       numLocks += 2 * NUM_SLRU_BUFFERS;

!       /* Create a few more for use by user-defined modules. */
!       numLocks += NUM_USER_DEFINED_LWLOCKS;
       return numLocks; }
--cut---------------
*** ./src/include/storage/lwlock.h      Sat Aug 20 16:26:34 2005
--- lwlock.h    Wed Oct  5 08:22:26 2005
***************
*** 53,58 ****
--- 53,62 ----       MaxDynamicLWLock = 1000000000 } LWLockId;
+ /*
+  * Allocate a few LWLocks for user-defined functions.
+  */
+ #define NUM_USER_DEFINED_LWLOCKS 4
 typedef enum LWLockMode {
--cut---------------


__
Marc Munro

On Tue, 2005-10-04 at 22:51 -0400, Tom Lane wrote:
> Marc Munro <marc@bloodnok.com> 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 LWLocks
> > available.
>
> Perhaps you missed the comment in NumLWLocks()?
>
>             regards, tom lane