Re: Resource Owner reassign Locks - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: Resource Owner reassign Locks
Date
Msg-id CAMkU=1x94AP2HXGm1q6z2KqmzURTDDurnhfwNibPcPNcA5CrPw@mail.gmail.com
Whole thread Raw
In response to Re: Resource Owner reassign Locks  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Resource Owner reassign Locks  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers

On Tue, Aug 25, 2015 at 5:48 AM, Michael Paquier <michael.paquier@gmail.com> wrote:
On Fri, Jul 10, 2015 at 4:22 AM, Andres Freund <andres@anarazel.de> wrote:
> On July 9, 2015 9:13:20 PM GMT+02:00, Jeff Janes <jeff.janes@gmail.com> wrote:
>
>>Unfortunately I don't know what that means about the API.  Does it mean
>>that none of the functions declared in any .h file can have their
>>signatures changed?  But new functions can be added?
>
> That's the safest way. Sometimes you can decide that a function can not sanely be called by external code and thus change the signature. But I'd rather not risk or here, IRS quite possible that one pod these is used by a extension.

Where are we on this? Could there be a version for <= 9.2?

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.  It is beyond what I feel comfortable trying to do, especially as I have no "test case" of 3rd party code to verify I haven't broken it.

I still think is a good idea, but for someone who knows more about linkers and .so files than I do.

If I were faced with upgrading a 9.2 instance with many tens of thousands of objects, I would just backpatch the existing code and compile it to make a binary used only for the purposes of the upgrade.

Cheers,

Jeff

pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Error message with plpgsql CONTINUE
Next
From: Tom Lane
Date:
Subject: Re: WIP: Rework access method interface