Re: Updating .so files for functions? - Mailing list pgsql-admin

From Dave Johansen
Subject Re: Updating .so files for functions?
Date
Msg-id CAAcYxUfjmwge+p9QsK4WWte96od8mvMu+nL83rGLWEzj6NgMJw@mail.gmail.com
Whole thread Raw
In response to Re: Updating .so files for functions?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-admin
On Sat, Feb 14, 2015 at 9:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Dave Johansen <davejohansen@gmail.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

pgsql-admin by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: PostgreSQL File System Based Backup Restartability
Next
From: girish R G peetle
Date:
Subject: Re: PostgreSQL File System Based Backup Restartability