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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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)

Attachment Content-Type Size
RemoveProcLock.patch text/plain 11.5 KB

Responses

Browse pgsql-patches by date

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