Re: SIGSEGV taken on 8.1 during dump/reload

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SIGSEGV taken on 8.1 during dump/reload
Date: 2005-11-13 06:46:33
Message-ID: 20051113064633.GA29881@filer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sysexperts(dot)com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joost Kraaijeveld 2005-11-13 06:48:05 prepareThreshold=1 and statement.executeBatch() ??
Previous Message Christopher Kings-Lynne 2005-11-13 06:15:14 Re: Multi-table-unique-constraint