Thread: General Bug Report: INSTALL and regression notes
============================================================================
POSTGRESQL BUG REPORT TEMPLATE
============================================================================
Your name : Michael Van Biesbrouck
Your email address : mlvanbie@thinkage.on.ca
Category : install: other
Severity : non-critical
Summary: INSTALL and regression notes
System Configuration
--------------------
Operating System : Linux 2.2.1 libc 5.4.44
PostgreSQL version : 6.5
Compiler used : gcc 2.7.2
Hardware:
---------
Linux valium 2.2.1 #4 Sat Feb 6 20:20:13 EST 1999 i586
AMD K6, 96MB RAM (was Slackware once upon a time)
Versions of other tools:
------------------------
GNU make, flex, etc.
--------------------------------------------------------------------------
Problem Description:
--------------------
1. LC_COLLATE appears twice:
LC_COLLATE=C
LC_CTYPE=C
LC_COLLATE=C
export LC_COLLATE LC_CTYPE LC_COLLATE
2. User told to add a lib directory owned by an insecure
userid (postgress) to ld.so.conf.
3. int2 and int4 test produce
ERROR: pg_atoi: error reading "100000": Math result not representable
instead of
ERROR: pg_atoi: error reading "100000": Numerical result out of range
4. horology regression test: I get PST instead of PDT and
-08 as a timezone instead of -07 on many lines. Am I
broken?
--------------------------------------------------------------------------
Test Case:
----------
--------------------------------------------------------------------------
Solution:
---------
1. One of these should be LC_LANG?
2. The lib directory should be put at the end to prevent
people from breaking into the PostgreSQL account and
replacing libc.so. Different arrangements might be
required on different machines and this might not
succeed if a program looks for a particular libc version
that hasn't been install.
On systems that support it, the -rpath options should
be used when building executables so that they know
where to find their libraries. See the Perl 5 build
scripts to find out how to do this on different machines.
3. Either put a FAQ entry or determine which libc versions
give this message and provide alternate expected files.
4. Not sure.
--------------------------------------------------------------------------
> Problem Description: > -------------------- > 1. LC_COLLATE appears twice: > > LC_COLLATE=C > LC_CTYPE=C > LC_COLLATE=C > export LC_COLLATE LC_CTYPE LC_COLLATE No, I think it is just a duplicate, and was removed from the sgml. Should be fixed when 6.5.1 is released. > > 2. User told to add a lib directory owned by an insecure > userid (postgress) to ld.so.conf. Well, not sure on this one. It is a good idea to put it in ld.so.conf. > 3. int2 and int4 test produce > ERROR: pg_atoi: error reading "100000": Math result not representable > instead of > ERROR: pg_atoi: error reading "100000": Numerical result out of range sys_errlist has different messages for different OS's. No way to make that portable. > 1. One of these should be LC_LANG? Does your OS have that. Can't find it on BSD/OS. > 2. The lib directory should be put at the end to prevent > people from breaking into the PostgreSQL account and > replacing libc.so. Different arrangements might be > required on different machines and this might not > succeed if a program looks for a particular libc version > that hasn't been install. Good idea, put it at the end of ld.so.conf, right? > > On systems that support it, the -rpath options should > be used when building executables so that they know > where to find their libraries. See the Perl 5 build > scripts to find out how to do this on different machines. It makes it easier for users to put it in ld.so.conf. > 3. Either put a FAQ entry or determine which libc versions > give this message and provide alternate expected files. How about text in regress/README: Error messages can come from either the Postgres code or from the host platform system routines. In the latter case, the messages may vary between platforms, but should reflect similar information. These differences in messages will result in a "failed" regression test which can be validated by inspection. > > 4. Not sure. ? -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <maillist@candle.pha.pa.us> writes:
>> On systems that support it, the -rpath options should
>> be used when building executables so that they know
>> where to find their libraries. See the Perl 5 build
>> scripts to find out how to do this on different machines.
> It makes it easier for users to put it in ld.so.conf.
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...
>> 3. Either put a FAQ entry or determine which libc versions
>> give this message and provide alternate expected files.
Something I'd like to see is a ".similar" mechanism for regress test
expected files, like we have for template files. There only seem
to be two popular wordings of that atoi overflow message, so there
should be no need to keep more than two expected files for the int2
and int4 tests; all we need is a file that lists which platforms
to use each one for. I think that'd be much easier to maintain than
the current approach is.
regards, tom lane
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/
> Something that I forgot to mention was that 20a is missing the & to > background postmaster -i. > Thanks. FIxed, and added nohup too. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026