Re: Weirdness using Executor Hooks
От | Eric Ridge |
---|---|
Тема | Re: Weirdness using Executor Hooks |
Дата | |
Msg-id | CANcm6wY3mUK9h8veEf6G+b6noo+w6J6V+fuXHK7Zg4ifrjirCg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Weirdness using Executor Hooks (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Weirdness using Executor Hooks
|
Список | pgsql-hackers |
On Thu, Jun 18, 2015 at 5:30 PM, Tom Lane <tgl@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
В списке pgsql-hackers по дате отправления: