[BUGS] BUG #8191: Wrong bit conversion
The following bug has been logged on the website: Bug reference: 8191 Logged by: Gerald Luger Email address: ger...@hexboss.com PostgreSQL version: 9.2.1 Operating system: Windows 8 Description: SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) RESULT: "1000", "0001", "0001" -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
[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] 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
Re: [BUGS] BUG #8191: Wrong bit conversion
Shouldn't I expect all results to be 000...0001? Otherwise it would be 1 != 1? -Original Message- From: Tom Lane [mailto:t...@sss.pgh.pa.us] Sent: Friday, May 31, 2013 5:34 PM To: Gerald Luger Cc: pgsql-bugs@postgresql.org Subject: Re: [BUGS] BUG #8191: Wrong bit conversion ger...@hexboss.com writes: > SELECT b'1'::bit(64), x'1'::bit(64), 1::bit(64) > RESULT: > "1000", > "0001", > "0001" I believe those are all operating as intended. regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
