[BUGS] Loss of significant digits on pg_dump
Patricia Holben ([EMAIL PROTECTED]) reports a bug with a severity of 2
The lower the number the more severe it is.
Short Description
Loss of significant digits on pg_dump
Long Description
This has been noticed on 7.0.3 and all betas/releases of 7.1. When data is stored as
a timestamp(see examples) and then is dumped and reloaded, display and math operations
present different results before vice after the dump. .
Sample Code
A more complete example can be generated by running the regression tests, dumping the
db, dropping the db, creating the db, loading the dumpfile,use psql to go into the
database, set datestyle = 'Postgres,Noneuropean'; select d1 from timestamp_tbl.
-
short example:
test=# create table timestamp_tbl (d1 timestamp);
CREATE
test=# insert into timestamp_tbl values ('Mon Feb 10 17:32:01.01 1997 PST');
INSERT 1305206 1
test=# select d1 from timestamp_tbl;
d1
---
1997-02-10 20:32:01.00-05
(1row)
test=# set datestyle = 'Postgres,NonEuropean';
SET VARIABLE
test=# select d1 from timestamp_tbl;
d1
-
Mon Feb 10 20:32:01.00 1997 EST
(1 row)
test=# insert into timestamp_tbl values ('Mon Feb 10 17:32:01.99 1997 PST');
INSERT 1305207 1
test=# select d1 from timestamp_tbl;
d1
-
Mon Feb 10 20:32:01.00 1997 EST
Mon Feb 10 20:32:02.00 1997 EST
(2rows)
now dump the db, drop, recreate, reload the data
test=# select d1 from timestamp_tbl;
d1
1997-02-10 20:32:01-05
1997-02-10 20:32:02-05
(2rows)
test=# set datestyle = 'Postgres,NonEuropean';
SET VARIABLE
test=# select d1 from timestamp_tbl;
d1
--
Mon Feb 10 20:32:01 1997 EST
Mon Feb 10 20:32:02 1997 EST
(2 rows)
-- now we insert 2 rows using identical inserts as above
test=# insert into timestamp_tbl values ('Mon Feb 10 17:32:01.01 1997 PST');
INSERT 1797129 1
test=# insert into timestamp_tbl values ('Mon Feb 10 17:32:01.99 1997 PST');
INSERT 1797130 1
-- now we expect the following math option to work the same on the pre-dump and
after-dump entries
test=# SELECT '' AS "53", date_part( 'year', d1) AS year, date_part( 'month', d1) AS
month,
test-# date_part( 'day', d1) AS day, date_part( 'hour', d1) AS hour,
test-# date_part( 'minute', d1) AS minute, date_part( 'second', d1) AS second
test-# FROM TIMESTAMP_TBL WHERE d1 BETWEEN '1902-01-01' AND '2038-01-01';
53 | year | month | day | hour | minute | second
+--+---+-+--++--
| 1997 | 2 | 10 | 20 | 32 |1
| 1997 | 2 | 10 | 20 | 32 |2
| 1997 | 2 | 10 | 20 | 32 | 1.01
| 1997 | 2 | 10 | 20 | 32 | 1.99
(4 rows)
No file was uploaded with this report
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Major Memory Leak in PostgreSQL JDBC Driver
At least the 7.1 RC3 driver has a memory leak in that the .../jdbc2/PreparedStatement.java class uses Java's ThreadLocal object for "optimization" reasons. However, Sun's J2SE 1.3 leaks memory whenever this class is used. Hence, repeated use of the JDBC driver's PreparedStatement class will cause a major memory leak. Our application running on the Orion application server using PostgreSQL will crash with an OutOfMemoryError in less than an hour while stress testing. Our workaround is to disable the ThreadLocal object by patching the driver before using it. The patch is simple and small; instead of using the ThreadLocal object to retrieve a thread-local SimpleDateFormat instance so that it doesn't have to be instantiated each time (this is the optimization), just instantiate the SimpleDateFormat class each time. We've noticed no performance loss and our application no longer has any memory leaks. Please consider fixing this problem before releasing 7.1. Thanks. Gerald. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] aliasing table name in update
Hi there, Upgrading from 7.0.3 to 7.1(rc4) went very smooth - but a small issue came up: The following statement does not work any more: update l set i=2 from longname l where l.i=1; Not a big problem, but you should know ;-) With kind regards / Mit freundlichem Gruß Holger Klawitter -- Holger Klawitter [EMAIL PROTECTED] http://www.klawitter.de ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[BUGS] When I install postgresql using rpm it is ok. When I compile the fonts and execute the initdb hapen a Error: unknown type 'ame'.
Marcos Roberto Henker ([EMAIL PROTECTED]) reports a bug with a severity of 3 The lower the number the more severe it is. Short Description When I install postgresql using rpm it is ok. When I compile the fonts and execute the initdb hapen a Error: unknown type 'ame'. Long Description initdb This database system will be initialized with username "postgres". This user will own all the data files and must also own the server process. Creating database system directory /usr/local/pgsql/data Creating database system directory /usr/local/pgsql/data/base Creating database XLOG directory /usr/local/pgsql/data/pg_xlog Creating template database in /usr/local/pgsql/data/base/template1 ERROR: Error: unknown type 'ame'. ERROR: Error: unknown type 'ame'. Creating global relations in /usr/local/pgsql/data/base ERROR: Error: unknown type 'ame'. ERROR: Error: unknown type 'ame'. Adding template1 database to pg_database /usr/local/pgsql/bin/initdb: line 484: 14049 segmentation failed (core dump) "$PGPATH"/postgres $BACKENDARGS template1 <"$TEMPFILE" initdb faile. Removing /usr/local/pgsql/data. Removing temp file /tmp/initdb.14049. Sample Code No file was uploaded with this report ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] Major problem in PostgreSQL JDBC driver that will cause OutOfMemoryErrors
The PostgreSQL JDBC ( bundled with 7.1 RC3 at least) driver makes use of Java's ThreadLocal class in the .../jdbc2/PreparedStatement.java class to hold onto DateFormat classes used during the setTImestamp() and setDate() calls. Sun's J2SE 1.3 has a major bug in the implementation of ThreadLocal in which progressive use leaks more and more memory. This means that as more PreparedStatements are used, more and more memory is leaked, and at a high rate. Eventually, the Java VM runs out of memory and any applications running within it will crash and burn. Our stress tests indicate that our application running on top of the Orion application server will crash with an hour after taking up all available memory when using this driver. A solution is to NOT use ThreadLocal in the PreparedStatement class. This solution works because ThreadLocal is used as an "optimization" to avoid allocating the DateFormat classes multiple times. On our site, we patched the RC3 JDBC driver to not use the ThreadLocal object and everything is runnning fine with no perceivable performance loss. Sun's bug report is here: http://developer.java.sun.com/developer/bugParade/bugs/4414045.html Gerald. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
