Re: [HACKERS] Re: Postgresql broken - Mailing list pgsql-hackers
From | Thomas G. Lockhart |
---|---|
Subject | Re: [HACKERS] Re: Postgresql broken |
Date | |
Msg-id | 34F98854.75E42903@alumni.caltech.edu Whole thread Raw |
In response to | Re: [HACKERS] Re: Postgresql broken (Cristian Gafton <gafton@redhat.com>) |
List | pgsql-hackers |
> > The test is to start up psql and try > > > > select '$1.00'::money; > > > > which fails. I believe this works on other platforms, and I distinctly recall getting > > That is true, it fails. However, if you could point to me where exactly > something is going wrong I could try and have a look at it. I don't really > feel like digging into postgresql source to see which functions are at > fault. A small C test program will be nice. Did you receive my mail dated 1998-02-28 03:02UTC? It contained a very small test program which (I believe) illustrates the problem. I've now modified it by dropping the relevant Postgres "money" support code straight into it; the new version is enclosed below. Just do golem> make testlocale cc testlocale.c -o testlocale To try it out. It _may_ just be illustrating my lack of understanding of the locale support code in Unix, but I'm pretty sure this works on other platforms (and used to work on an older - 3.03? 4.0? 4.1? - RH installation). > > 2) pre-glibc2.0.7 has rounding bugs which cause odd results in some date/time > > routines. The test is to try > > > > select '4 hours'::timespan; > > Yepp, it fails. Dwight reported success when upgrading to a newer glibc but I didn't see a change when trying the glibc in your home directory area. Oliver (I think??) reported success with Debian with a newer glibc, so perhaps things are fixed and I just didn't do the right things to have the machine use the new library. > > which will return '3 hours 59 mins 60 secs' on a machine with problems. We have > > reports from someone running Debian that glibc2.0.7-pre1 (?) fixes the problem. Any > > idea on when glibc2.0.7 might be available? > > the 2.0.7pre1 is available. However, if the debian folks fixed this > problem, I can tell you that their patch didn't made it so far in the > glibc source tree. Again, a small C test program that shows what exactly > fails will be nice. OK. I'll work on it and try getting it to you soon. As I recall, it is problems with rounding behavior in one of the math functions (maybe modf()??). Anyway, will let you know. > > 3) the ownership of the data area is incorrect as shipped (I assume this is > > rpm-specific). On my RH5.0 machine, which is a VAResearch system with Linux/Postgres > > preinstalled, the data area was owned by root, and the backend cannot start up. If > > the ownership is changed to the postgres account then the backend starts. > > I think that is a VAResearch thing. The package definitely installs the > /var/lib/pgsql directory owned by postgres account. OK. > > Thanks for building a new RPM. I'll try it at work on my production machine tomorrow. > > Also, we will have new documentation in v6.3, including html and hardcopy, and you > > will want to repackage that too. Look in the doc directory (in a day or two; I'm > > still building the docs and haven't committed anything yet to the source tree). > > I am still waiting to find out a way to get cvs read-only access to the > postgres sources. Downloading a full snapshot evey other day is not my > favorite game. Especially when a nice shell script can take care of > automatically generating new rpms every day... :-) We are using CVSup. I built a static version on RH4.2 and placed it on ftp://postgresql.org/pub/CVSup/cvsup-15.2-client-linux-static.tar.gz There is a non-static image also, but it probably requires some Modula-3 libraries. Hey, that brings up something: would you be interested in a Modula-3 rpm? It would make installing CVSup much easier, since I wouldn't have to do the static library thing. Actually, I'd be willing to build the rpm (or at least the source rpm) or even better help set up someone at RH, but I don't know much about rpm building and have been working so much on Postgres that I really don't want to start from scratch on figuring it out. I found that it built fairly easily, but it takes 200MB (!!) to do the build. The installation footprint is much smaller. It's a nice environment, and apparently let John Polstra, the CVSup developer, do his project fairly easily. Talk to you soon... - Tom #include <stdlib.h> #include <stdio.h> #include <time.h> #include <limits.h> #include <locale.h> struct lconv *lconvert; int main(int argc, char **argv) { int fpoint; char dsymbol, ssymbol, psymbol, nsymbol, csymbol; if (argc > 1) printf( "locale set to %s\n", setlocale(LC_MONETARY, getenv(argv[1]))); #if FALSE printf( "locale set to %s\n", setlocale(LC_MONETARY, "C")); #endif lconvert = localeconv(); /* frac_digits in the C locale seems to return CHAR_MAX */ /* best guess is 2 in this case I think */ #if FALSE fpoint = ((lconvert->frac_digits != CHAR_MAX) ? lconvert->frac_digits : 2); /* int_frac_digits? */ #endif fpoint = lconvert->frac_digits; /* int_frac_digits? */ dsymbol = *lconvert->mon_decimal_point; ssymbol = *lconvert->mon_thousands_sep; csymbol = *lconvert->currency_symbol; psymbol = *lconvert->positive_sign; nsymbol = *lconvert->negative_sign; printf( "numeric decimal point '%c'\n", *lconvert->decimal_point); printf( "cashin- frac digits '%d'; mon decimal '%c'; mon thousands '%c'; currency '%c'; positive '%c'; negative '%c'\n", fpoint, dsymbol, ssymbol, csymbol, psymbol, nsymbol); exit(0); }
pgsql-hackers by date: