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