On 11/28/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > On Tue, Nov 28, 2006 at 03:23:36PM -0500, Tom Lane wrote:
> >> I'd suggest putting together a simple stand-alone test case and filing
> >> a bug report against glibc.
>
> > How can glibc do anything about this? dlopen() mmaps the .so into
> > memory and the cp overwrites what was mmaped, changing what is in
> > memory.
>
> The test case I was using involved a cp -f that overwrote the .so with
> the exact same data (ie, I didn't bother recompiling, just cp -f a
> second time from the compilation output file). So if the above were
> the explanation there should have been no crash; moreover, if that were
> the explanation then the cp-without-dash-f case should crash too.
>
> I suspect that glibc is playing some undocumented games and is getting
> confused because the file's inode number has changed.
also, if what Martijn is saying is correct, wouldn't that make the
LOAD command unsupportably dangerous? The postgresql documentation
suggests its use is for updating libraries in exactly this way
(emphasis mine):
This command loads a shared library file into the PostgreSQL server's
address space. If the file had been loaded previously, it is first
unloaded. This command is primarily useful to unload and reload a
shared library file that *has been changed since the server first
loaded it*. To make use of the shared library, function(s) in it need
to be declared using the CREATE FUNCTION command.
merlin
