On 2015-08-25 13:54:20 -0400, Tom Lane wrote: > Jeff Janes <jeff.ja...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
