Re: Updating .so files for functions?

On Sat, Feb 14, 2015 at 9:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dave Johansen <davejohansen(at)gmail(dot)com> writes:
> > I ran into a crash that was caused by the .so files used by postgres
> being
> > overwritten ( see
> >
> http://www.postgresql.org/message-id/CAAcYxUeduPhKXbDQ6ZTOhKGE+1A3cMrTQujSExC-tv4ac4ksUw@mail.gmail.com
> > ), so that made me wonder what the rules are for updating .so files. I
> read
> > through the documentation on C functions (
> > http://www.postgresql.org/docs/8.4/static/xfunc-c.html ) but didn't
> come to
> > any firm answers.
>
> > Here's our current procedure:
> > 1) Build new .so files
> > 2) Put new .so files in "version directory" (for example
> > /path/to/funcs/1.23.1/ where old version was /path/to/funcs/1.23.0/)
> > 3) Run "ALTER DATABASE <db_name> SET dynamic_library_path TO
> > '/path/to/funcs/1.23.1:$libdir';"
>
> > Is that an ok operation to perform on a live database? Will existing
> > connections handle that without issues? (I'm ok if they still keep using
> > the old .so files until the connection is closed and re-opened)
>
> That should be safe enough, I'd think (noting that already-launched
> sessions would keep using the old libraries, since ALTER DATABASE
> settings are only adopted at session start).
>

Ok, good to hear.

> What I'm wondering about is if someone made an ABI-incompatible change
> to one of the functions provided by the libraries, and adjusted their
> SQL declarations to match. Then you'd had problems with some sessions
> seeing new SQL declarations and old libraries.
>

To date we've never done such a thing, but that's good to keep in mind and
if we ever do that, then we'll be sure to handle it in a more safe manner.

Thanks,
Dave