Thread

  1. Re: [BUGS] General Bug Report: INSTALL and regression notest

    Michael Van Biesbrouck <mlvanbie@thinkage.on.ca> — 1999-07-12T17:28:26Z

    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/