Re: Resource Owner reassign Locks

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2015-08-25 13:54:20 -0400, Tom Lane wrote:
>> However, I'm not entirely following Andres' concern here. AFAICS,
>> the only externally visible API change in commit eeb6f37d8 was that
>> LockReleaseCurrentOwner and LockReassignCurrentOwner gained some
>> arguments. That would certainly be an issue if there were any plausible
>> reason for extension code to be calling either one --- but it seems to me
>> that those functions are only meant to be called from resowner.c. What
>> other use-case would there be for them?

> I don't think it's super likely, but I don't think it's impossible that
> somebody created their own resource owner.

How would they have done that without major code surgery? We don't have
any hooks or function pointers involved in the users of resowner.h.
Certainly locks would not be getting passed to a nonstandard resowner.

> Say because they want to
> perform some operation and then release the locks without finishing the
> transaction. Adding a zero argument
> LockReleaseCurrentOwner()/LockReassignCurrentOwner() wrapper seems like
> a small enough effort to simply not bother looking for existing callers.

I agree that a wrapper is possible, but it's not without cost; both as to
the time required to modify the patch, and as to possibly complicating
future back-patching because the code becomes gratuitously different in
the back branches. I really don't see that a wrapper is appropriate here.

regards, tom lane