On 2015-08-25 13:54:20 -0400, Tom Lane wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
> > Once the code has to be rewritten, my argument that it has been working "in
> > the field" for a while doesn't really apply anymore.
If rewriting involves adding two one line wrapper functions, I don't see
the problem.
> 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. 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.
> Were any follow-on commits needed to fix problems induced by eeb6f37d8?
> I couldn't find any in a quick trawl of the commit logs, but I could have
> missed something.
I don't remember any at least.
Andres
