On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > If that's broken, then so are most of our contrib modules. > Certainly none of them have an extra check as suggested by Andres.
I'm putting it in anyways, along with a guard in the actual hook function to ERROR if prev_hook == my_hook. At least that'll avoid the endless loops until I can figure this out. > >> As a data point, that might be interesting to know, but I'd still be >> scratching my head about how it happened. Postgres doesn't load an >> extension library more than once per backend session, does it? > > It's not supposed to, and AFAICS internal_load_library() will treat > either an exact pathname match or an inode-number match as being > "already loaded". I wonder if you might be doing something that > confuses those checks. It does not look like we try terribly hard > to canonicalize library pathnames --- might you have some references > under different relative paths, for instance? The inode number > check would perhaps fail if you'd installed a new library version, > but it's unclear to me why the pathname check would fail. According to the docs, anything listed in 'local_preload_libraries' has to be in $libdir/plugins (whereas extensions just go to $libdir), so rather than duplicate the .so, the "copy" in $libdir/plugins is just a symlink to ../my_extension.so. Could that be confusing things? eric -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
