Tom Lane wrote:
> I'm still planning to work on replacing our ad-hoc Makefile.shlib
> support with GNU libtool. That should make most of these issues
> go away --- libtool knows about -rpath, for example. In the meantime,
> I'm not too excited about expending effort on improving Makefile.shlib
> beyond where it is.
> I'm not sure if I will get to this for 6.6 --- I have other to-do
> items that I consider higher priority. If someone else is more
> interested and wants to take on the project, be my guest...
Switching to libtool would be good. This is what I wrote about security
problems before realizing that things should be going onto a mailing list:
Entries in ld.so.conf should not point to directories that can be modified
by unsecure users. According to the man page for ld.so on my machine,
it is possible to not put /usr/lib and /lib in ld.so.conf -- they will
be searched after LD_LIBRARY_PATH and ld.so.cache. Even if /usr/lib and
/lib are in the ld.so.conf file, I think that there is still a problem.
If the minor version of the library is out of date with respect to
executables that exist (possibly provided by a commercial vendor ... I
see this happen all the time with netscape), then those executables will
load the shared library put in by an intruder on some (all?) systems.
On locales I wrote:
I goofed when writing this ... I meant LANG. You can see it in the
example of what happens to perl if the locale variables are set
incorrectly. (In the locale support section of INSTALL.) LC_ALL is
also mentioned in that section. LC_MONETARY, LC_NUMERIC and LC_TIME
might also exist. PostgreSQL probably should be affected by all of these.
I also noted:
After submitting my bug report, I tried the bigtest regression suite.
The numeric_big seems to go into an infinite loop, or is very
time-consuming. Has this problem ever been reported? numeric_big.out
QUERY: DELETE FROM num_result;
QUERY: INSERT INTO num_result SELECT id, 0, POWER('10'::numeric, LN(ABS(round(va
WHERE val != '0.0';
It looks like this is the last test and should be followed by the lines
SELECT t1.id1, t1.result, t2.expected
FROM num_result t1, num_exp_power_10_ln t2
WHERE t1.id1 = t2.id
AND t1.result != t2.expected;
and a result. Perhaps flushing would have caused more output. Lots of
the bigtest regression tests are failing now, even though they didn't fail
the first time that I ran the test procedure. Perhaps the database has
been corrupted by the test that failed.
Something that I forgot to mention was that 20a is missing the & to
background postmaster -i.
# -- Michael Van Biesbrouck, mlvanbie(at)thinkage(dot)on(dot)ca
In response to
pgsql-bugs by date
|Next:||From: Bruce Momjian||Date: 1999-07-12 17:31:48|
|Subject: Re: [BUGS] General Bug Report: INSTALL and regression notest|
|Previous:||From: Tom Lane||Date: 1999-07-12 14:47:15|
|Subject: Re: [BUGS] General Bug Report: INSTALL and regression notest |