Tomas Vondra <tv@fuzzy.cz> writes:
> On 30.5.2012 22:35, Tom Lane wrote:
>> Tomas Vondra <tv@fuzzy.cz> writes:
>>> whenever I run a C-function (part of an .so file) and the file is
>>> overwritten, the connection crashes. Tested on 9.1.3 and 9.2-beta1.
>> What exactly would you expect Postgres to do about such a thing, anyway?
>> It has no control over people overwriting its executable files.
> Well, I expected the existing connection will use the old .so, while new
> connections would use the new version (although they're exactly the
> same).
Well, that would be something to discuss with the implementors of shared
library functionality on your platform, not with us.
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.
> 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.
regards, tom lane