Re: SIGSEGV taken on 8.1 during dump/reload - Mailing list pgsql-hackers

From Kevin Brown
Subject Re: SIGSEGV taken on 8.1 during dump/reload
Date
Msg-id 20051113064633.GA29881@filer
Whole thread Raw
In response to Re: SIGSEGV taken on 8.1 during dump/reload  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: SIGSEGV taken on 8.1 during dump/reload  (Martijn van Oosterhout <kleptog@svana.org>)
List pgsql-hackers
Tom Lane wrote:
> On the other hand, it'd be relatively easy for clueless lusers to
> defeat; I can readily imagine someone copying foo.so.8.2 to foo.so.8.3
> when the backend complained that it couldn't find the latter.  So
> maybe it's not what we want.

Hmm...but isn't the version number also something that can be stored
in the shared library itself during link time (e.g., via the -soname
option to the linker)?  The manpage for ld under Linux implies that
this will cause the executable that's linked against the shared object
to look explicitly for a library with the soname specified by the
shared object.  I don't know if that just causes the dynamic linker to
look for a file with the specified soname or if it will actually
examine the shared object under consideration to make sure it has the
DT_SONAME field in question, however.


-- 
Kevin Brown                          kevin@sysexperts.com


pgsql-hackers by date:

Previous
From: Christopher Kings-Lynne
Date:
Subject: Re: Multi-table-unique-constraint
Next
From: Kris Jurka
Date:
Subject: Re: [JDBC] prepareThreshold=1 and statement.executeBatch() ??