| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
| Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, PgSQL General <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: backend crash following load command |
| Date: | 2006-11-28 20:37:40 |
| Message-ID: | 6028.1164746260@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Martijn van Oosterhout <kleptog(at)svana(dot)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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2006-11-28 20:42:01 | Re: backend crash following load command |
| Previous Message | Martijn van Oosterhout | 2006-11-28 20:30:19 | Re: backend crash following load command |