Refactoring in lock.c - Mailing list pgsql-patches

From Alvaro Herrera
Subject Refactoring in lock.c
Date
Msg-id 20050513030659.GA25439@surnet.cl
Whole thread Raw
Responses Re: Refactoring in lock.c  (Alvaro Herrera <alvherre@surnet.cl>)
Re: Refactoring in lock.c  (Neil Conway <neilc@samurai.com>)
Re: Refactoring in lock.c  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Patchers,

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.)


Additionally, I found that no callers of LockReleaseAll and LockRelease
had any use for their return values, so I made them return void.

There are two exceptions to the "no use of return value" assertion: one
is the userlock contrib module, but I doubt it has much use for it in
reality;  I made it "return true" where it used LockRelease{,All} return
value, in order not change the function's signature; users have no way
to recover when user_unlock_all does not work anyway, so we are not
losing anything.

The other exception is LockReleaseCurrentOwner, where the only action
is to raise a WARNING.  Since LockRelease already raises WARNING for
anything that returns a FALSE value, we don't lose anything by just
returning void and dropping the warning in ResourceOwners.

Please apply if there are no objections.

--
Alvaro Herrera (<alvherre[a]surnet.cl>)
"La libertad es como el dinero; el que no la sabe emplear la pierde" (Alvarez)

Attachment

pgsql-patches by date:

Previous
From: Tom Lane
Date:
Subject: Re: AllocSetReset improvement
Next
From: Neil Conway
Date:
Subject: hash index work