From: | Tomas Vondra <tv(at)fuzzy(dot)cz> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: overwriting an existing .so while being used crashes the server process |
Date: | 2012-05-30 21:43:35 |
Message-ID: | 4FC69487.7000106@fuzzy.cz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
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
From | Date | Subject | |
---|---|---|---|
Next Message | postgresuser | 2012-05-31 00:24:49 | BUG #6668: hashjoin cost problem |
Previous Message | Tom Lane | 2012-05-30 21:37:05 | Re: pg_dump/pg_restore with time zone displacement out of range |