On 30.5.2012 23:19, Tom Lane wrote:
> I suspect it depends on how you install the new version of the library,
> too. I would somewhat expect it to work as you're thinking if the
> install consists of "rename old file out of the way, copy new file into
> place, unlink old file" or equivalent. If you are actually
> *overwriting* the file in place, a crash does not seem especially
> surprising --- it would make perfect sense if the kernel expects the
> file to be usable as backing store for the in-memory image, which is not
> exactly unreasonable. IOW, if the in-memory bits we're executing are
> just an mmap'd image of the .so file, changing the .so file could
> entirely be expected to lead to a crash.
Aha! That might be the culprit - I've just tested that deleting the olf
file and copying new version (thus not overwriting it) did not cause a
crash. Funny.
>> http://www.postgresql.org/docs/9.1/interactive/xfunc-c.html
>
>> After it is used for the first time, a dynamically loaded object
>> file is retained in memory. Future calls in the same session to the
>> function(s) in that file will only incur the small overhead of a
>> symbol table lookup. If you need to force a reload of an object
>> file, for example after recompiling it, begin a fresh session.
>
>> Which kinda looks like my expectation that the session won't crash was
>> correct. Clearly seems like bug to me.
>
> No, that just means that we don't unload it from memory. Where the bits
> actually are, and whether the kernel has defenses against somebody
> modifying the executable, is not something you should be asking us.
> Talk to a kernel hacker for your platform.
OK, thanks for the explanation.
I still think it's worth mentioning this issue in the docs ...
Tomas
