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(at)bloodnok(dot)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