[BUGS] zlib directory in configure.
Hi all, Is it possible to improve "configure" script of postgresql to allow to specify in which directory a 3rd tool is installed ? An option like --with-zlib=[DIR] is very usefull because w/ the current (7.4.1) configure script, you have to set by yourself some variables to specify where is installed zlib if it isn't in the "standard" directory. Many other tool using "configure" allows this kind of configuration ... Thanks & regards, Laurent = The misspelling master is on the Web. _100 % Dictionnary Free ! //( / Dico / / Pleins d'autres fautes sur // /http://go.to/destroyedlolo (###( / http://destroyedlolo.homeunix.org:8080 Quoi, des fautes d'orthographe! Pas possible ;-D. Yahoo! Mail : votre e-mail personnel et gratuit qui vous suit partout ! Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] memory does not return back
On Wednesday 18 February 2004 05:54, hessam wrote: > Dear Richard, > > Thank you for your reply.Below are results of ps and top commands on > my new linux Box: > > There are 64 database connection made by freeradius.When I reboot my > machine with 'chkconfig postgresql off' 'chkconfig radiusd off' . > nothing happens and everything is normal.Then I just start postgresql > and do "select * form mytable;" memory goes up . The more select I do > from different table, the more memory usage becomes.(whithout > freeradius).And memory does not return back,but when I restart > postgresql it goes down from 1GB to about 300Mb at the begining but > after just minutes it reaches the top.Then I reboot linux with > postgresql at the begining it is about 200 Mb but it takes hours to > reach 1GB. I see no evidence of high memory usage in the trace below - indeed the largest memory usage is by the RedHat network config applet. If you look at the figures, you have 144028KB used for buffering (144MB) and 960924KB for file cache (960MB) along with 0 swap used. > 08:56:26 up 18:51, 3 users, load average: 0.01, 0.02, 0.00 > 133 processes: 132 sleeping, 1 running, 0 zombie, 0 stopped > CPU0 states: 1.0% user 2.0% system0.0% nice 0.0% iowait > 96.3% idle > CPU1 states: 1.0% user 1.1% system0.0% nice 0.0% iowait > 97.2% idle > Mem: 2064420k av, 1512876k used, 551544k free, 0k shrd, > 144028k buff > 495576k actv, 377752k in_d, 369380k in_c > Swap: 2040244k av, 0k used, 2040244k free > 960924k cached > > PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU > COMMAND > 2514 root 15 0 4000 4000 1340 S 1.3 0.1 2:48 0 > radiusd > 3089 root 15 0 6092 6088 5060 S 1.3 0.2 13:00 1 > magicdev > 18985 root 16 0 1184 1184 856 R 0.7 0.0 0:00 0 top > 2365 root 15 0 2972 2972 1436 S 0.3 0.1 0:08 0 cupsd > 2599 postgres 15 0 5208 5208 3984 S 0.3 0.2 0:04 0 > postmaster > 2609 postgres 15 0 5196 5196 3992 S 0.3 0.2 0:04 0 > postmaster > 2718 root 16 0 1200 1200 856 S 0.3 0.0 3:39 1 top > 3096 root 15 0 13408 13M 8704 S 0.3 0.6 10:27 1 rhn- > applet-gu [snip] You do know that the "1512876k used" includes all this buffer/cache memory and isn't really "in use"? If not, do some searching on Google for terms like "linux out of memory buffer cache" - it confuses everybody the first time they come across it. Tip: try "free -m" $ free -m total used free sharedbuffers cached Mem: 975213761 0 12101 -/+ buffers/cache: 99875 Swap: 1027 0 1027 Here the important values are on the second line - 99MB used, 875MB free. If you still think there is a problem, can you show the output of "top" when your system's memory usage increases. Tip: press "M" (not "m") to sort the output by memory usage. -- Richard Huxton Archonet Ltd ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[BUGS] Select (str)::FLOAT8 BUG
Hi!, I think i have found a bug. I´ve tried it in PgSQL 7.3.5 & 7.4.1 When I do: atisae_oct_1=# SELECT (1000/500/7)::FLOAT8 as v_numero; v_numero -- 0 (1 row) atisae_oct_1=# SELECT 1000/500/7::FLOAT8 as v_numero; v_numero --- 0.285714285714286 (1 row) atisae_oct_1=# SELECT (1000/500/7)::NUMERIC as v_numero; v_numero -- 0 (1 row) atisae_oct_1=# SELECT 1000/500/7::NUMERIC as v_numero; v_numero 0.28571428571428571429 (1 row) Why is different: 'SELECT (x)::FLOAT8' than 'SELECT x::FLOAT8' Thanks in advance... Rafa. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] Select (str)::FLOAT8 BUG
My guess would be... 1000/5000/7::FLOAT8 is really 1000::INT/500::INT/7::FLOAT8 (int may be some other integer type) whereas (1000/500/7)::FLOAT8 is (1000::INT/500::INT/7::INT)::FLOAT8 i.e. the resultan integer is casted to type FLOAT8 after the maths has been done on integers. Thats what I'd expect. Iain > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Rafael Villalobos > Prats > Sent: Wednesday, February 18, 2004 3:38 PM > To: [EMAIL PROTECTED] > Subject: [BUGS] Select (str)::FLOAT8 BUG > > > Hi!, > > I think i have found a bug. > > I´ve tried it in PgSQL 7.3.5 & 7.4.1 > > When I do: > > atisae_oct_1=# SELECT (1000/500/7)::FLOAT8 as v_numero; > v_numero > -- > 0 > (1 row) > > atisae_oct_1=# SELECT 1000/500/7::FLOAT8 as v_numero; > v_numero > --- > 0.285714285714286 > (1 row) > > atisae_oct_1=# SELECT (1000/500/7)::NUMERIC as v_numero; > v_numero > -- > 0 > (1 row) > > atisae_oct_1=# SELECT 1000/500/7::NUMERIC as v_numero; > v_numero > > 0.28571428571428571429 > (1 row) > > > Why is different: 'SELECT (x)::FLOAT8' than 'SELECT x::FLOAT8' > > Thanks in advance... > > Rafa. > > ---(end of > broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [BUGS] Select (str)::FLOAT8 BUG
Ok, that's right. Many thanks Rafa-. -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Fothergill, Iain Enviado el: miércoles, 18 de febrero de 2004 16:31 Para: [EMAIL PROTECTED] Asunto: Re: [BUGS] Select (str)::FLOAT8 BUG My guess would be... 1000/5000/7::FLOAT8 is really 1000::INT/500::INT/7::FLOAT8 (int may be some other integer type) whereas (1000/500/7)::FLOAT8 is (1000::INT/500::INT/7::INT)::FLOAT8 i.e. the resultan integer is casted to type FLOAT8 after the maths has been done on integers. Thats what I'd expect. Iain > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Rafael Villalobos > Prats > Sent: Wednesday, February 18, 2004 3:38 PM > To: [EMAIL PROTECTED] > Subject: [BUGS] Select (str)::FLOAT8 BUG > > > Hi!, > > I think i have found a bug. > > I´ve tried it in PgSQL 7.3.5 & 7.4.1 > > When I do: > > atisae_oct_1=# SELECT (1000/500/7)::FLOAT8 as v_numero; > v_numero > -- > 0 > (1 row) > > atisae_oct_1=# SELECT 1000/500/7::FLOAT8 as v_numero; > v_numero > --- > 0.285714285714286 > (1 row) > > atisae_oct_1=# SELECT (1000/500/7)::NUMERIC as v_numero; > v_numero > -- > 0 > (1 row) > > atisae_oct_1=# SELECT 1000/500/7::NUMERIC as v_numero; > v_numero > > 0.28571428571428571429 > (1 row) > > > Why is different: 'SELECT (x)::FLOAT8' than 'SELECT x::FLOAT8' > > Thanks in advance... > > Rafa. > > ---(end of > broadcast)--- > TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly <> ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] Select (str)::FLOAT8 BUG
"Rafael Villalobos Prats" <[EMAIL PROTECTED]> writes: > Why is different: 'SELECT (x)::FLOAT8' than 'SELECT x::FLOAT8' The :: operator binds more tightly than most other operators. As Iain replied, most of your divisions are going to be integer divisions that discard the fractional part. You can either add casts or add ".0" to your numbers to cause them to be considered non-integers. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
