Re: Fixed directory locations in installs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fixed directory locations in installs
Date
Msg-id 23008.1083510153@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fixed directory locations in installs  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: Fixed directory locations in installs
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> Peter Eisentraut wrote:
>> This is just going to open up the possibility of silently finding the 
>> wrong files.

> Maybe it could be improved by using more version markers?

AFAICS the sharedir will already be sufficiently checked by means of
initdb's check on the postgres.bki version marker.  In some sense, the
sharedir used by initdb is the *right* one for an installation by
definition --- I'm not even convinced that we should allow people to
fool with this after the fact.  (However, it's probably not worth the
trouble to develop a non-GUC mechanism to transmit the setting from
initdb to backend.)

We could add a version-marker file to libdir, but it'd not really be a
sufficient check since people might copy their own shlibs in there from
a prior installation without recompiling; and as soon as someone adds
more directories to dynamic_library_path, all bets are off anyway.
We've seen the "wrong version of plpgsql.so" symptom often enough that
I've thought seriously of insisting on a backend-version marker embedded
right into shlibs loaded by the backend.  This'd be easy enough if we
were willing to demand a source code addition in loadable modules, say
a macroBACKEND_VERSION_MARKER
which'd compile to some sort of preinitialized global variable or constant
function returning a version string.  I haven't been able to think of a
way to insert such a marker without source-level cooperation though.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Fixed directory locations in installs
Next
From: Tom Lane
Date:
Subject: Re: Fixed directory locations in installs