[BUGS] BUG in postgres mathematic
Postgres-7.0.3-2 RedHat-6.2 SELECT int8(5*27.81*100); 13904 SELECT int4(5*27.81*100); 13905 SELECT int8(27.81*100*5); 13905 -- ó Õ×ÁÖÅÎÉÅÍ, ÷ÁÝÅÎËÏ íÁËÓÉÍ, îÉÖÅÇÏÒÏÄÓËÉÅ ÉÎÆÏÒÍÁÃÉÏÎÎÙÅ ÓÅÔÉ (8312) 30-19-05, 34-00-02, 30-09-73 With best regards, Max Vaschenko, Nizhny Novgorod Information Networks.
[BUGS] JDBC driver throws SQLException while parsing timestamp
Alexander Dietrich ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
JDBC driver throws SQLException while parsing timestamp
Long Description
Hi,
there's a discrepancy between PreparedStatement.setTimestamp() and
ResultSet.getTimestamp() related to a timestamp format that may or
may not be valid (sorry I can't give a complete code sample):
-
I do something like this to store the timestamp:
Connection conn = ConnectionFactory.getConnection();
PreparedStatement stmt = conn.prepareStatement(getInsertString());
[...]
stmt.setTimestamp(5, new Timestamp(System.currentTimeMillis()));
stmt.executeUpdate();
-
This is an example of what ends up in the database:
type: timestamp, value: "2001-01-25 11:33:19.50+01"
(Checked with psql)
-
But when retrieving the data:
[...]
ResultSet rs = stmt.executeQuery(queryStr);
Timestamp timestamp = rs.getTimestamp("CREATION_TIME");
An SQLException is thrown:
Bad Timestamp Format at 19 in 2001-01-25 11:33:19.50+01
java.lang.Throwable()
java.lang.Exception()
java.sql.SQLException()
org.postgresql.util.PSQLException(java.lang.String, java.lang.Object, java.lang.Object)
java.sql.Timestamp org.postgresql.jdbc2.ResultSet.getTimestamp(int)
java.sql.Timestamp org.postgresql.jdbc2.ResultSet.getTimestamp(java.lang.String)
[...]
-
Obviously the getTimestamp() method chokes on the millisecond field
in the timestamp. A timestamp like "2001-01-25 11:33:19+01" does not
pose a problem.
My configuration is:
Server:
RedHat 7.0 (x86), 2.2.16-22
postgresql-server-7.0.3-2
postgresql-7.0.3-2
postgresql-jdbc-7.0.3-2
Client:
JVM: 1.2.2 inside VisualAge 3.5 Patch 2
JDBC driver: jdbc7.0-1.2.jar
Regards,
Alexander Dietrich
Sample Code
No file was uploaded with this report
[BUGS] large objects overwriting bug
([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description large objects overwriting bug Long Description When overwriting an lo with a larger lo, the old data is not overwritten. This was supposed to be fixed in 6.5, but it happens in 7.0.3. Sample Code No file was uploaded with this report
Re: [BUGS] BUG in postgres mathematic
This problem is not specific to Postgres. If you play around with a little C
program like:
#include
int main(int argc, char * argv[])
{
float f = 27.81;
int i = 5;
int l = 100;
int ii = i*f*l;
long ll = l*f*i;
float ff = i*f*l;
printf("%i\n", ii);
printf("%li\n", ll);
printf("%.5f\n", ff);
printf("%i\n", (int) ff);
}
It prints:
13904
13904
13905.0
13905
There is probably a good explanation for this. gcc 2.95 and egcs 2.91.66 do
this. Maybe a rounding problem.
On Thursday 25 January 2001 05:34, Max Vaschenko wrote:
> Postgres-7.0.3-2
> RedHat-6.2
>
> SELECT int8(5*27.81*100);
> 13904
>
> SELECT int4(5*27.81*100);
> 13905
>
> SELECT int8(27.81*100*5);
> 13905
--
Robert B. Easter [EMAIL PROTECTED] -
-- CompTechNews Message Board http://www.comptechnews.com/ --
-- CompTechServ Tech Services http://www.comptechserv.com/ --
-- http://www.comptechnews.com/~reaster/
Re: [BUGS] Re: [INTERFACES] jdbc driver: Support for 'BOOL'
Quoting Bruce Momjian <[EMAIL PROTECTED]>: > > Is this a bug? Can someone submit a patch? Why not setBoolean(parameterIndex,((Boolean)x),booleanValue()); Also, unless it's changed postgres accepts 't' & 'f' not 'true' or 'false'? Also, which PreparedStatement.java are we taking about, as there are 2 of them? Peter > > > [ Charset ISO-8859-1 unsupported, converting... ] > > "Jos? Antonio Matute Calvo" wrote: > > > > > > Problem: > > > If try to use field of type "java.sql.Types.BIT" obtains error > "Unknown > > > Types Value" > > > > > > Resolution: > > > > > > Add this: > > > > > > PreparedStatement.java > > > 460,461d459 > > > < case Types.BIT: > > > < set(parameterIndex, > > > ((Boolean)x).booleanValue() ? "true" : "false"); > > > > Why not set(parameterIndex,x.toString())? > > > > > > -- > > Joseph Shraibman > > [EMAIL PROTECTED] > > Increase signal to noise ratio. http://www.targabot.com > > > > > -- > Bruce Momjian| http://candle.pha.pa.us > [EMAIL PROTECTED] | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup.| Drexel Hill, Pennsylvania > 19026 > -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [BUGS] JDBC buggy in 7.1beta3
Quoting Bruce Momjian <[EMAIL PROTECTED]>: > > Anyone fixing this bug? > > > I reported a JDBC bug in the 7.1 beta1 release back in December and > notice that the same bug is still present in the current beta 3 sources. > The problem relates to nested cursors failing and is quite simple to > reproduce. A simple test case can be found at: > > > > http://www.twospuds.com/pg7-1b3-jdbc-bug.tar.gz > > > > The 7.0.2 JDBC drivers work fine against the 7.1b3 backend, with a > little tweaking for "long" rows. > > > > Peter (Mount) did acknowledge the bug but I have not heard anything on > the list since then. Is anyone looking at it? Come to think of it, I As I've said numerous times on lists and direct to people, I've had several major problems which have hampered things since November, but I am now slowly catching up. The problems have been: * 2 SCSI discs dying on my linux box 2 weeks ago * changing ISP's (now resolved) * Changing jobs, which mean I have to limit how much time I can spend at the moment. * UK Dialup has been horrendous this last week Now, my linux box is up and running, but no networking. Due to my job Thursday evenings are out now (learning German), so I can't finish of its rebuild before Saturday. This is holding things up because I don't have a 7.1 backend to test against (& I can't get it to build under NT yet either). So while she's down, I've been doing other things that either don't need a backend to test, or (in the case of the XML stuff) test against Oracle. What may be of use, is for people to email me again with any known bugs, so I can compile a list of what needs to be done before 7.1, or what has already been done/obsoleted or re-written from scratch. This weekend I'm planning on: Sat am: finish rebuild of linux box Sat pm: test current cvs against current 7.1beta Sun am: catch up with bug list Sun pm: If time, move over more stuff into contrib Peter -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
Re: [JDBC] [BUGS] no way in LargeObject API to detect short read?
Quoting [EMAIL PROTECTED]: > Paul M. Aoki ([EMAIL PROTECTED]) reports a bug with a severity of 3 > The lower the number the more severe it is. > > Short Description > no way in LargeObject API to detect short read? Will check to see how libpq (which this API is based on) handles this. I've got on my list of Saturday items the stream support, which will need this. Peter > > Long Description > org.postgresql.largeobject.LargeObject.read(byte[],int,int) returns void > instead of int. there's therefore no reliable, non-exceptional way to > detect short reads. > > the natural way to write blocked-read loops would be to assume that > read(byte[],int,int) returned the number of bytes read or (e.g.) -1 on > EOF. > > Sample Code > > > No file was uploaded with this report > > > -- Peter Mount [EMAIL PROTECTED] PostgreSQL JDBC Driver: http://www.retep.org.uk/postgres/ RetepPDF PDF library for Java: http://www.retep.org.uk/pdf/
[BUGS] round - timestamp bug
POSTGRESQL BUG REPORT TEMPLATE
Your name : Gonzalo Arana
Your email address : [EMAIL PROTECTED]
System Configuration
-
Architecture (example: Intel Pentium) : Intel Pentium III
Operating System (example: Linux 2.0.26 ELF) : Linux 2.2.12-20 ELF
(libc-2.1.2)
PostgreSQL version (example: PostgreSQL-7.0): PostgreSQL-7.0.3
Compiler used (example: gcc 2.8.0) : egcs-2.91.66
Please enter a FULL description of your problem:
It seems that there is a problem when retrieving a timestamp value (rounding).
NO minute has 61 seconds. Am I wrong?
Please describe a way to repeat the problem. Please try to provide a
concise reproducible example, if at all possible:
--
radius=# create table x (x timestamp);
CREATE
radius=# insert into x (x) values ('Tue 23 Jan 21:38:59.997 2001');
INSERT 619178 1
radius=# select * from x;
x
-
Tue 23 Jan 21:38:60.00 2001 ART
(1 row)
If you know how this problem might be fixed, list the solution below:
-
Ugly patch to scripts:
radius=# select to_char(x,'Dy DD Mon HH24:MI:SS ') from x;
to_char
--
Tue 23 Jan 21:38:59 2001
(1 row)
Of course, you'll lose the fraction of seconds otherwise are available.
Re: [BUGS] no way in LargeObject API to detect short read?
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Anyone able to fix this?
here's a hack we've been using in-house (written by Jun Gabayan,
<[EMAIL PROTECTED]>).
you may not like the style but it's a stab at a solution.
--
Paul M. Aoki / Xerox Palo Alto Research Center / Coyote Hill Road
[EMAIL PROTECTED] / Computer Science Laboratory / Palo Alto, CA 94304-1314
Index: LargeObject.java
===
RCS file:
/project/placeless/cvsroot/placeless2/src/org/postgresql/largeobject/LargeObject.java,v
retrieving revision 1.1
retrieving revision 1.3
diff -r1.1 -r1.3
64c64,67
<
---
>
> private int pos = 0; //current position
> private int size = 0;
>
85a89,90
> pos = tell();
> size = size();
102a108
> if(fd == 0) return;
105a112
> fd = 0;
118a126,132
> // calculate available data to read to avoid reading pass the end
> // to avoid an exception
> pos = tell();
> int avail = size - pos;
> if(avail == 0) return null;
> if(avail < len) len = avail;
> try {
123c137,141
<
---
> }catch(SQLException se) {
> System.out.println("***LargeObject.read: Caught SQLException: " +
>se.getMessage());
> return null;
> }
>
157c175
< public void read(byte buf[],int off,int len) throws SQLException
---
> public int read(byte buf[],int off,int len) throws SQLException
159c177,180
< System.arraycopy(read(len),0,buf,off,len);
---
> byte mybuf[] = read(len);
> int sz = (mybuf != null) ? mybuf.length : -1; //must return -1 for end of data
> if(sz > 0) System.arraycopy(mybuf,0,buf,off,sz);
> return sz;
[BUGS] select fails on indexed varchars.
Hi,
First off I'm running:
links=# select version() ;
version
-
PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc egcs-2.91.66
(1 row)
Now, if I have a table with an index, I'm not able to do some selects on
it. To reproduce:
links=# create table foo ( a char(25) );
CREATE
links=# create index foodx on foo (a);
CREATE
links=# insert into foo values ('Test/Test');
INSERT 29689 1
links=# select * from foo;
a
---
Test/Test
(1 row)
links=# select * from foo where a like 'Test/%'
links-# ;
a
---
(0 rows)
# Strange result, why 0 rows, the select failed.
links=# select * from foo where a like 'Test%';
a
---
Test/Test
(1 row)
# This one's fine.
links=# select * from foo where a like 'Test/T%';
a
---
Test/Test
(1 row)
# And so is this one.
It seems the /% causes a problem. If I drop the index, the selects work
fine. Is this a bug, am I missing something? If you need any other
system info, please let me know. I did an RPM install on a pretty plain
Redhat 6.2 system.
Please reply to [EMAIL PROTECTED] with any ideas.
Thanks!
Alex
Gossamer Threads Inc. --
Alex KrohnEmail: [EMAIL PROTECTED]
Internet Consultant Phone: (604) 687-5804
http://www.gossamer-threads.com Fax : (604) 687-5806
[BUGS] Re: round - timestamp bug
On Wed, Jan 24, 2001 at 05:50:24PM -0300, Gonzalo Arana <[EMAIL PROTECTED]> wrote: > > It seems that there is a problem when retrieving a timestamp value (rounding). > > NO minute has 61 seconds. Am I wrong? When leap seconds occur, minutes can have 61 seconds.
[BUGS] pl/pgsql documentation
Darcy ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description pl/pgsql documentation Long Description The following documentation does not apear to reflect real world use. [<>] FOR record | row IN select_clause LOOP statements END LOOP; (as snipped from http://postgresql.readysetnet.com/users-lounge/docs/7.0/postgres/c40914117.htm) Sample Code CREATE TABLE major_groups(id SERIAL, name TEXT); INSERT INTO major_groups(name) VALUES 'one'; INSERT INTO major_groups(name) VALUES 'two'; INSERT INTO major_groups(name) VALUES 'three'; CREATE FUNCTION test3(INT4) RETURNS INT4 AS ' DECLARE loc INT4; BEGIN loc := $1; for i IN (select id from major_groups) loop ( loc := $loc + $i; ) end loop; return $loc; end; ' language 'plpgsql'; select test3(2); NOTICE: plpgsql: ERROR during compile of test3 near line 10 ERROR: parse error at or near ";" No file was uploaded with this report
Re: [BUGS] round - timestamp bug
> radius=# create table x (x timestamp);
> CREATE
> radius=# insert into x (x) values ('Tue 23 Jan 21:38:59.997 2001');
> INSERT 619178 1
> radius=# select * from x;
> x
> -
> Tue 23 Jan 21:38:60.00 2001 ART
> (1 row)
>
> radius=# select to_char(x,'Dy DD Mon HH24:MI:SS ') from x;
> to_char
> --
> Tue 23 Jan 21:38:59 2001
> (1 row)
The to_char() is directly based on 'tm' struct and in current version
not use 'fsec' from timestamp2tm(). Hmm... I add it to my TODO.
I not sure if I fix it for 7.1, may be as late as in 7.1.1 :-(
It is not fatal bug it is almost feature that SS return directly sec :-)
Karel
Re: [BUGS] pl/pgsql documentation
Ok this has since been sorted out, however I propose that it is better layed out in the documentation, or at the veryleast an example is given. i MUST be defined as a RECORD, and you then refrence the returned result as RECORD.field, Also you can NOT have ()'s arouns the select statement. CREATE FUNCTION test3(INT4) RETURNS INT4 AS ' DECLARE loc INT4; iRECORD; BEGIN loc := $1; FOR i IN SELECT id FROM major_groups LOOP loc := loc + i.id; END LOOP; RETURN loc; END; ' LANGUAGE 'plpgsql'; select test3(2); >Short Description >pl/pgsql documentation > >Long Description >The following documentation does not apear to reflect real world use. > >[<>] >FOR record | row IN select_clause LOOP >statements >END LOOP; > >(as snipped from http://postgresql.readysetnet.com/users-lounge/docs/7.0/postgres/c40914117.h tm) > >Sample Code >CREATE TABLE major_groups(id SERIAL, name TEXT); >INSERT INTO major_groups(name) VALUES 'one'; >INSERT INTO major_groups(name) VALUES 'two'; >INSERT INTO major_groups(name) VALUES 'three'; > >CREATE FUNCTION test3(INT4) RETURNS INT4 AS ' > DECLARE >loc INT4; > BEGIN >loc := $1; >for i IN (select id from major_groups) loop > ( > loc := $loc + $i; > ) >end loop; >return $loc; > end; >' language 'plpgsql'; > >select test3(2); > >NOTICE: plpgsql: ERROR during compile of test3 near line 10 >ERROR: parse error at or near ";" > > >No file was uploaded with this report > > >
Re: [BUGS] large objects overwriting bug
[EMAIL PROTECTED] writes: > When overwriting an lo with a larger lo, the old data is not overwritten. This was >supposed to be fixed in 6.5, but it happens in 7.0.3. Please try your test case in 7.1beta3 or later. The large-object support has been rather completely rewritten ... if this bug is still there, then we need to know about it. regards, tom lane
Re: [BUGS] BUG in postgres mathematic
"Robert B. Easter" <[EMAIL PROTECTED]> writes: > This problem is not specific to Postgres. The fact that 5*27.81*100 != 27.81*100*5 is certainly a garden-variety floating-point roundoff error. However, I think Max has a fair complaint here: it seems float-to-int8 conversion is truncating, not rounding like the other conversions to integer do. regression=# select 4.7::float8::int4; ?column? -- 5 (1 row) regression=# select 4.7::float8::int8; ?column? -- 4 (1 row) Seems to me this is a bug we should fix. regards, tom lane
Re: [BUGS] select fails on indexed varchars.
Alex Krohn <[EMAIL PROTECTED]> writes: > links=# select * from foo where a like 'Test/%' > links-# ; > a > --- > (0 rows) This looks like an artifact of the known problems with LIKE index optimization in non-ASCII locales. What locale are you running the postmaster in? regards, tom lane
Re: [BUGS] BUG in postgres mathematic
On Thursday 25 January 2001 22:52, Tom Lane wrote: > "Robert B. Easter" <[EMAIL PROTECTED]> writes: > > This problem is not specific to Postgres. > > The fact that 5*27.81*100 != 27.81*100*5 is certainly a garden-variety > floating-point roundoff error. However, I think Max has a fair > complaint here: it seems float-to-int8 conversion is truncating, not > rounding like the other conversions to integer do. > > regression=# select 4.7::float8::int4; > ?column? > -- > 5 > (1 row) > > regression=# select 4.7::float8::int8; > ?column? > -- > 4 > (1 row) > > Seems to me this is a bug we should fix. > > regards, tom lane Yeah, I agree. It isn't right that it truncates and that is something C does appearently. The fix is to pass the float through a rounding something like (long)(f + 0.5) or else C just truncates it off. This must already be happening for the int4 conversion or C would do the same thing to it. I didn't look at the Postgres sources yet, but it is probably one of those very easy things to fix. :) -- Robert B. Easter [EMAIL PROTECTED] - -- CompTechNews Message Board http://www.comptechnews.com/ -- -- CompTechServ Tech Services http://www.comptechserv.com/ -- -- http://www.comptechnews.com/~reaster/
[BUGS] Re: Postgres int rounding
Is postgres going to use the scientific method of rounding or just the simple one? Or even make it configurable. As I recall, the scientific method says that 4.5 should be rounded to 4 and 5.5 should be rounded to 6. The idea was that even numbers were easier to work with and rounding all the x.5 numbers up as the common method says will eventually skew your average. Rounding evens down and odds up would probably generate a number of bug reports from people who are not aware of this though... -Michael > The fact that 5*27.81*100 != 27.81*100*5 is certainly a > garden-variety floating-point roundoff error. However, I think > Max has a fair complaint here: it seems float-to-int8 conversion > is truncating, not rounding like the other conversions to integer > do. > > regression=# select 4.7::float8::int4; > ?column? > -- > 5 > (1 row) > > regression=# select 4.7::float8::int8; > ?column? > -- > 4 > (1 row) > > Seems to me this is a bug we should fix. _ http://fastmail.ca/ - Fast Free Web Email for Canadians
