Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Ok, new version of this patch, adjusted per your comments. Thanks.
Applied with revisions. I backed off the idea of removing LockRelease's
return value after looking at contrib/userlock; it seems possible that
some applications out there are depending
Ok, new version of this patch, adjusted per your comments. Thanks.
--
Alvaro Herrera ()
"Hay que recordar que la existencia en el cosmos, y particularmente la
elaboración de civilizaciones dentre de él no son, por desgracia,
nada idílicas" (Ijon Tichy)
Index: contrib/userlock/user_locks.c
==
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Here is a small patch to refactor common functionality out of
> LockRelease and LockReleaseAll, creating a new static function
> RemoveProcLock.
> (This comes from Heikki's two-phase commit patch, where it is used more.)
I was just looking at this code
On Wed, May 18, 2005 at 12:33:51PM +1000, Neil Conway wrote:
> Alvaro Herrera wrote:
> >Additionally, I found that no callers of LockReleaseAll and LockRelease
> >had any use for their return values, so I made them return void.
>
> Is there a reason we can't just elog(ERROR) rather than returning?
Alvaro Herrera wrote:
Additionally, I found that no callers of LockReleaseAll and LockRelease
had any use for their return values, so I made them return void.
Is there a reason we can't just elog(ERROR) rather than returning?
-Neil
---(end of broadcast)--
On Thu, May 12, 2005 at 11:06:59PM -0400, Alvaro Herrera wrote:
Hackers,
> Here is a small patch to refactor common functionality out of
> LockRelease and LockReleaseAll, creating a new static function
> RemoveProcLock.
Any word on this patch? This is nearly trivial stuff.
--
Alvaro Herrera (
