Re: Fixed directory locations in installs
От | Tom Lane |
---|---|
Тема | Re: Fixed directory locations in installs |
Дата | |
Msg-id | 23008.1083510153@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Fixed directory locations in installs (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Fixed directory locations in installs
|
Список | 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 по дате отправления: