Skip site navigation (1) Skip section navigation (2)

Refactoring in lock.c

From: Alvaro Herrera <alvherre(at)surnet(dot)cl>
To: Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Refactoring in lock.c
Date: 2005-05-13 03:06:59
Message-ID: 20050513030659.GA25439@surnet.cl (view raw or flat)
Thread:
Lists: 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)

Responses

pgsql-patches by date

Next:From: Neil ConwayDate: 2005-05-13 05:13:48
Subject: hash index work
Previous:From: Michael PaesoldDate: 2005-05-12 19:06:28
Subject: Re: patches for items from TODO list

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group