pg.ddx.io pgsql-admin@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Updating .so files for functions? 3+ messages / 2 participants [nested] [flat]
* Updating .so files for functions? @ 2015-02-13 22:58 Dave Johansen <davejohansen@gmail.com> 0 siblings, 1 reply; 3+ messages in thread From: Dave Johansen @ 2015-02-13 22:58 UTC (permalink / raw) To: pgsql-admin 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.... ), 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) Thanks, Dave ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Updating .so files for functions? @ 2015-02-14 16:33 Tom Lane <tgl@sss.pgh.pa.us> parent: Dave Johansen <davejohansen@gmail.com> 0 siblings, 1 reply; 3+ messages in thread From: Tom Lane @ 2015-02-14 16:33 UTC (permalink / raw) To: Dave Johansen <davejohansen@gmail.com>; +Cc: pgsql-admin 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.... > ), 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). 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. regards, tom lane -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin ^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: Updating .so files for functions? @ 2015-02-18 17:44 Dave Johansen <davejohansen@gmail.com> parent: Tom Lane <tgl@sss.pgh.pa.us> 0 siblings, 0 replies; 3+ messages in thread From: Dave Johansen @ 2015-02-18 17:44 UTC (permalink / raw) To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: 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.... > > ), 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 ^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2015-02-18 17:44 UTC | newest] Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2015-02-13 22:58 Updating .so files for functions? Dave Johansen <davejohansen@gmail.com> 2015-02-14 16:33 ` Tom Lane <tgl@sss.pgh.pa.us> 2015-02-18 17:44 ` Dave Johansen <davejohansen@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox