Re: Facing issue with driver postgresql-9.2-1003.jdbc4 on PostgreSQL 9.2.4 - Mailing list pgsql-jdbc
From | Dave Cramer |
---|---|
Subject | Re: Facing issue with driver postgresql-9.2-1003.jdbc4 on PostgreSQL 9.2.4 |
Date | |
Msg-id | CADK3HH++K+M02WT7OAS9Ls9F5i6YAOM47uQP6N+Y5WosbLY=ig@mail.gmail.com Whole thread Raw |
In response to | Re: Facing issue with driver postgresql-9.2-1003.jdbc4 on PostgreSQL 9.2.4 (Nishant Singh <nishant.singh@egsgroup.com>) |
List | pgsql-jdbc |
Nishant,
Please let me know if you run into any other issues.
Thanks,
On Mon, Jul 29, 2013 at 11:54 AM, Nishant Singh <nishant.singh@egsgroup.com> wrote:
Hi Dave,
We have decided to use the new driver with binaryTransfer=false.
Thanks for your help.
Regards,
NishantOn 29/07/2013 16:37, Dave Cramer wrote:Nishant,Yes, pretty much the same except there were other enhancements, bug fixes.On Mon, Jul 29, 2013 at 11:36 AM, Nishant Singh <nishant.singh@egsgroup.com> wrote:Hi Dave,
Thanks for the information.
Does that mean the behaviour with binaryTransfer=false in postgresql-9.2-1003.jdbc4 is same as what we have with postgresql-9.1-903.jdbc4 driver ?
Regards,
NishantOn 29/07/2013 16:20, Dave Cramer wrote:Nishant,Binary transfer was added and I think I am going to default it to false going forward. It *should* be faster but apparently there are some bugs in it.DaveOn Mon, Jul 29, 2013 at 11:16 AM, Nishant Singh <nishant.singh@egsgroup.com> wrote:Hi,
binaryTransfer=false corrected the problem (I changed url to "jdbc:postgresql://localhost:5434/db?binaryTransfer=false").
What is the difference between postgresql-9.2-1003.jdbc4 and postgresql-9.1-903.jdbc4 drivers in terms of binaryTransfer?
Regards,
NishantOn 29/07/2013 14:37, Dave Cramer wrote:Nishant,The old driver should work fine with pg 9.2 I am wondering if this is an artifact of the binary transfer,Can you try with binaryTransfer=falseOn Mon, Jul 29, 2013 at 9:14 AM, Nishant Singh <nishant.singh@egsgroup.com> wrote:Hi Dave,
Thanks for your reply.
In my latest test I have noticed that with new jdbc driver (postgresql-9.2-1003.jdbc4.jar), out of total 512 records only first 125 records are having non-null value for type 'character varying[15)[]' field and for the rest of the records (from 126 to 512) field value is null.
But with old jdbc driver (postgresql-9.1-903.jdbc4.jar) all 512 records are having non-null value for type 'character varying[15)[]' field. File Comparison-of-results.jpg shows the comparison of test logs (OldDriverWithCursor.txt and NewDriverWithCursor.txt) for the two drivers.
I am not sure whether above is of any help in understanding the actual problem or not.
By the way we are planning to revert back to old jdbc driver (postgresql-9.1-903.jdbc4.jar) on the live environment having PostgreSQL 9.2.4 till we can find any solution for the problem.
Do you think that there can be some issue (in general) with old jdbc driver(postgresql-9.1-903.jdbc4.jar) and PostgreSQL 9.2.4 combination?
Regards,
NishantOn 29/07/2013 11:41, Dave Cramer wrote:Nishant,Your email does suggest there is a bug in there somewhere. However we would require a bit more of a detailed test case in order to be able to help find it.Regards,On Fri, Jul 26, 2013 at 11:54 AM, Nishant Singh <nishant.singh@egsgroup.com> wrote:Hi,
My Java web application uses PostgreSQL. It has a document table with one of the field called accountCode of type character varying(15)[]
In the logic table records are accessed through cursor. Thats is being done through Apache Torque.(schema.xml: ...<table name="document" idMethod="native">... <column name="accountCode" type="CLOB" javaName="AccountCodeString"/>..)
PostgreSQL log for the cursor are as follows:
2013-07-26 15:14:00 BST 9592 efed-328 postgresLOG: execute <unnamed>: DECLARE CursIt4 CURSOR FOR SELECT document.DOCUMENTID, document.DOCUMENTNUMBER, document.ADHOCDOCUMENTNUM, document.ORGUNITID, document.ACCOUNTID, document.TEMPLATEID, document.REFDOCUMENTID, document.DOCUMENTTITLE, document.STATUSID, document.STATUSSTR, document.DOCUMENTDATE, document.MODTYPEID, document.DELETEFLAG, document.CURRENTSTEP, document.ITEMSREADONLY, document.ISCLOSEDFOREINVOICING, document.ENABLEAUTOACDISTRIBUTION, document.MODDATE, document.DEADLINE, document.ACCOUNTCODE, document.EXTERNALID, document.MULTIPLESHIPPING, document.MULTIPLEBILLING, document.MULTIPLEACCOUNTING, document.DOCUMENTDESCRIPTION, document.REVISERNAME, document.REVISEREMAIL, document.REVISERORGUNITNAME, document.FORWARDREFID, document.REVISIONDATE, document.RESPONSEVENDORID, document.RESPONSECATALOGUEID, document.COURIERNAME, document.COURIERTRACKINGNO, document.WORKFLOWINSTANCEID, document.WORKFLOWEVALUATED, document.PURCHASEORDERVENDORID, document.PURCHASEORDERCATALOGUEIDS, document.NOTIFYSUPPLIER, document.PURCHASEORDERVARIANT, document.MOD, document.ISQUICKORDER, document.CONFIRMATIONORDER, document.WITHDRAWNFROMAPPROVAL, document.SHIPPINGDATE, document.FMSNAME, document.EXTERNAL_REF_ID, document.ISCISORDER, document.ISPROXY, document.ORIGINAL_PO_ID, document.NUMBER_OF_VARIATIONS, document.ORIGINAL_ORDER_DATE, document.SHARED_SECRET FROM document, organizationalUnit WHERE document.ISPROXY<>1 AND organizationalUnit.ORGID=15136 AND document.STATUSID IN (1457,1456,1459,1458,1453,1466,1452,1455,1454,1450,1461,1470,1451) AND document.ORGUNITID=organizationalUnit.ORGUNITID
...
2013-07-26 15:14:00 BST 9592 efed-328 postgresLOG: execute <unnamed>: FETCH 25 FROM CursIt4
...
We have recently moved to PostgreSQL 9.2.4 and JDBC driver postgresql-9.2-1003.jdbc4.jar. But we have noticed that now accountcode field is not getting populated in the Java code. Same is happening with postgresql-9.2-1002.jdbc4.jar
Earlier with PostgreSQL 9.1.4 and JDBC driver postgresql-9.1-903.jdbc4.jar we were getting accountCode field populated in the Java code.
But when we change to JDBC driver postgresql-9.1-903.jdbc4.jar on PostgreSQL 9.2.4 it works fine.
Are new drivers (postgresql-9.2-1003.jdbc4 and postgresql-9.2-1002.jdbc4) having some bug which is causing this problem or there can be some other reason?
Thanks in advance.
Regards,
NishantThis message has been scanned for malware by SurfControl plc. www.surfcontrol.com
pgsql-jdbc by date: