Re: [BUGS] General Bug Report: INSTALL and regression notest - Mailing list pgsql-bugs
From | Michael Van Biesbrouck |
---|---|
Subject | Re: [BUGS] General Bug Report: INSTALL and regression notest |
Date | |
Msg-id | 199907121728.NAA14968@Thinkage.On.CA Whole thread Raw |
In response to | Re: [BUGS] General Bug Report: INSTALL and regression notest (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [BUGS] General Bug Report: INSTALL and regression notest
|
List | pgsql-bugs |
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 ends with QUERY: DELETE FROM num_result; QUERY: INSERT INTO num_result SELECT id, 0, POWER('10'::numeric, LN(ABS(round(va l,1000)))) FROM num_data 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@thinkage.on.ca :b^Js/\(.*\)\(,.*\):\1\(.\)\([a-z]*\)\(.\)r\(:.*\)>\3/\4\2:\1\3\4\5r\6\5>/ s/\(.*\)\(,.*\):\1\(.\)\([a-z]*\)\(.\)l\(:.*\)\(.\)>\3/\4\2:\1\3\4\5l\6>\7\5/ s/>$/>0/^J/^halt/!bb^J# http://www.csclub.uwaterloo.ca/u/mlvanbie/
pgsql-bugs by date: