Re: [BUGS] storage sync failed on magnetic disk: Permission denied
"Valery Bondarenko" <[EMAIL PROTECTED]> writes: > When the cluster performs a massive disk operations (like nightly > vacuuming or smth) > I offten got such error in log file: > 2005-11-12 14:52:29 LOG: could not fsync segment 0 of relation > 1663/17735/210608: Permission denied > It looked like as if somebody (not postgres) got an exclusive access to > that file. We've heard reports of various "antivirus" products doing that sort of thing ... what third-party software do you have installed? regards, tom lane ---(end of broadcast)--- TIP 1: 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
[BUGS] BUG #2037: user function call unexpected "input out of range"
The following bug has been logged online: Bug reference: 2037 Logged by: Tom Email address: [EMAIL PROTECTED] PostgreSQL version: 8.1-beta4 Operating system: Windows XP Description:user function call unexpected "input out of range" Details: --No database needs to be selected. --Just cut and paste into a file. --All remarks are in comments. -- --From the psql prompt use "\i fileName". -- create function find (numeric,numeric,numeric,numeric) returns double precision as $$ --Calculate distance select acos ( sin($1*pi()/180)*sin($3*pi()/180) + cos($1*pi()/180)*cos($3*pi()/180) *cos(($2-$4)*pi()/180) )*60*1.1515*180/pi(); $$ language SQL; --Number 1. select find(42.3202,-83.2687,42.3202,-83.2687); --Number 2. select find(42.320,-83.2687,42.3202,-83.2687); --Number 3. select find(42.3338,-83.1818,42.3338,-83.1818); \df+ find; drop function find(numeric,numeric,numeric,numeric); /* This surfaced when calculating the distances between zip codes using latidtudes and longitudes. When the latitudes and longitudes are the same the distance should be zero. Number 1 gives the error. Number 2 differs by a digit in the last decimal place and works. Number 3 is another test with identical latitudes and longitudes and does calculate zero. The "DROP FUNCTION" was only put in so I could repeatly re-execute the script. The ".msi" was used for the install accepting all of the defaults. Thanks, Tom */ ---(end of broadcast)--- TIP 1: 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
[BUGS] BUG #2038: fetch items truncated
The following bug has been logged online: Bug reference: 2038 Logged by: wgh Email address: [EMAIL PROTECTED] PostgreSQL version: 8.0 Operating system: window Description:fetch items truncated Details: I use PowerBuilder8.0, i use ODBC to connect postgers8,i was in china,i use chinese, it have datawindow error :fetch item error!! ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2037: user function call unexpected "input out of range"
"Tom" <[EMAIL PROTECTED]> writes: > Description:user function call unexpected "input out of range" Why does this surprise you? Floating point computation is inherently inexact, so coming out with a value fractionally greater than 1 for the acos() argument doesn't seem all that unlikely. You probably ought to add some code to clamp the result to the legal range. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] BUG #2037: user function call unexpected "input out of range"
On Fri, Nov 11, 2005 at 09:26:47PM +, Tom wrote: > This surfaced when calculating the distances between zip codes using > latidtudes and longitudes. When the latitudes and longitudes are the same > the distance should be zero. Number 1 gives the error. Number 2 differs by a > digit in the last decimal place and works. Number 3 is another test with > identical latitudes and longitudes and does calculate zero. If you use psql and increase VERBOSITY you can see where the error is happening: test=> \set VERBOSITY verbose test=> select find(42.3202,-83.2687,42.3202,-83.2687); ERROR: 22003: input is out of range CONTEXT: SQL function "find" statement 1 LOCATION: dacos, float.c:1602 "dacos" is the internal name of PostgreSQL's acos() function. I'd guess the value that acos() receives is a wee bit bigger than 1.0 due to rounding and the inaccuracy of representing floating point numbers in binary; you don't see the problem with another pair of identical locations because the value calculated to the 16th or so digit is slightly different. Your function uses the law of cosines; consider using haversine instead. http://www.movable-type.co.uk/scripts/GIS-FAQ-5.1.html If you're working with geospatial data then you might want to look at PostGIS. http://postgis.refractions.net/ See also PostgreSQL's contrib/earthdistance module. -- Michael Fuhr ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [BUGS] storage sync failed on magnetic disk: Permission denied
"Tom Lane" <[EMAIL PROTECTED]> wrote >> When the cluster performs a massive disk operations (like nightly >> vacuuming or smth) >> I offten got such error in log file: >> 2005-11-12 14:52:29 LOG: could not fsync segment 0 of relation >> 1663/17735/210608: Permission denied > >> It looked like as if somebody (not postgres) got an exclusive access to >> that file. > > We've heard reports of various "antivirus" products doing that sort of > thing ... what third-party software do you have installed? > The strange thing is that this time it gets an EACCESS this time. What we get before is "Invalid Argument" message which is a mis-translation of ERROR_SHARING_VIOLATION. Let's see what he installed ... Regards, Qingqing ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [BUGS] BUG #2037: user function call unexpected "input out of range"
On Fri, Nov 11, 2005 at 09:26:47PM +, Tom wrote: > > The following bug has been logged online: > > Bug reference: 2037 > Logged by: Tom > Email address: [EMAIL PROTECTED] > PostgreSQL version: 8.1-beta4 > Operating system: Windows XP > Description:user function call unexpected "input out of range" > Details: [ basically acos(sin(w1)*sin(w2) + cos(w1)*cos(w2)*cos(l1-l2)) ] Seems to me that you are hitting an unfortunate roundoff error, where the argument to acos is slightly greater than 1 (it will be mathematically 1 in the case w1==w2 and l1==l2). Maybe you should limit the argument to acos to -1..+1? regards -- tomás signature.asc Description: Digital signature
Re: [BUGS] BUG #2037: user function call unexpected "input out of range"
On Fri, Nov 11, 2005 at 21:26:47 +, Tom <[EMAIL PROTECTED]> wrote: > > --Calculate distance > select acos > ( > sin($1*pi()/180)*sin($3*pi()/180) > + > cos($1*pi()/180)*cos($3*pi()/180) > *cos(($2-$4)*pi()/180) > )*60*1.1515*180/pi(); In addition to the other comments, you don't want to calculate distance this way. It isn't very accurate when $2 and $4 are nearly equal which is the normal case. Do a search for haversine. ---(end of broadcast)--- TIP 1: 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] storage sync failed on magnetic disk: Permission denied
"Valery Bondarenko" <[EMAIL PROTECTED]> wrote: > Situation first occurs on _CLEAN_ Win2k server with 8.0.0 Installed by his > installer (woops :) ). > And it continues to... > Also I got it in a realy "dirty" environment with 8.1. > > But in both cases there were no antiviruses and (AFAIK) no product which > could do such locking. We have a loop in pgunlink/pgrename for Win32 since it is possible that some other processes hold the opened file (without the required flags) when we want to drop/rename it. Here seems comes the similar situation, but not sure the exact reason that leads to it though ... The situtation has been there for a while, check out this thread and see if you can catch the killer (the analysis part is bogus according to Tom): http://archives.postgresql.org/pgsql-hackers/2005-08/msg00129.php Regards, Qingqing ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] BUG #2038: fetch items truncated
""wgh"" <[EMAIL PROTECTED]> wrote > > I use PowerBuilder8.0, i use ODBC to connect postgers8,i was in china,i > use > chinese, it have datawindow error :fetch item error!! > Does ODBC returns any non SQL_SUCCESS information? To find it out, enable the ODBC trace log and search for it. Regards, Qingqing ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [BUGS] ECPG: "char*" instead of "const char*" in ecpglib.h
On Wed, 9 Nov 2005, Tomasz Ostrowski wrote: > > Using "char*" as an argument type instead of "const char*" in ecpglib.h > causes that for example the following sample program, basically > copied from docmentation > http://www.postgresql.org/docs/8.1/interactive/ecpg-dynamic.html , > does not compile using "gcc-4.0.1": > > $g++ test.c -lecpg > test.pgc: In function 'int main()': > test.pgc:11: error: invalid conversion from 'const char*' to 'char*' > test.pgc:11: error: initializing argument 3 of 'bool ECPGprepare(int, > char*, char*)' > Agreed. A patch has been submitted to pg-patches. Regards, Qingqing ---(end of broadcast)--- TIP 1: 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] BUG #2030: Chinese character support error
""Dragon"" <[EMAIL PROTECTED]> wrote > > When I install postgresql server,I can not find the chinese charactor > GB2312 > or GBK or GB18310 , and In the pgAdmin III when I create a database, in > the > Dialog I can not select Encoding GBK or other Chinese Encoding, > "A error orccured > Error :GBK is not a validate encoding name" > GBK or GB18030 are only for client encoding. So you can't initdb or createdb using these encodings. Regards, Qingqing ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
