vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| Hi, it's a follow-up of bug #3999 ( http://archives.postgresql.org/pgsql...2/msg00268.php ) We have a homemade application (tomcat 4.1.31 and jdk1.5.0_06 on RHES 3/x86_64) which uses pg74.216.jdbc3.jar. Sometimes, on our database, we have some PANIC after a weird error : ERROR: invalid string enlargement request size 1358954492 WARNING: AbortTransaction and not in in-progress state ERROR: could not send data to client: Broken pipe PANIC: error during error recovery, giving up Here is a excerpt from the tcpdump log (only incoming cnx) : 000000BA 51 00 00 00 24 73 65 74 20 63 6c 69 65 6e 74 5f Q...$set client_ 000000CA 65 6e 63 6f 64 69 6e 67 20 3d 20 27 55 4e 49 43 encoding = 'UNIC 000000DA 4f 44 45 27 00 ODE'. 000000DF 58 51 00 00 00 04 XQ.... We noticed than the 58 51 couple of bytes is unusual. It seems to indicate a try to finish connection and then to reuse it for a query. We would like to know if it's a known bug of the jdbc connector for example, or if we have a problem with our application's code (maybe doing a close request and a query request on the same connection ?). Thanks in advance. -- Thomas Poindessous -- Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_www...tra=pgsql-jdbc |
| ||||
| On Mon, 3 Mar 2008, Thomas Poindessous wrote: > it's a follow-up of bug #3999 ( > http://archives.postgresql.org/pgsql...2/msg00268.php ) > > We have a homemade application (tomcat 4.1.31 and jdk1.5.0_06 on RHES > 3/x86_64) which uses pg74.216.jdbc3.jar. > > Sometimes, on our database, we have some PANIC after a weird error : > > ERROR: invalid string enlargement request size 1358954492 > WARNING: AbortTransaction and not in in-progress state > ERROR: could not send data to client: Broken pipe > PANIC: error during error recovery, giving up > > Here is a excerpt from the tcpdump log (only incoming cnx) : > > 000000BA 51 00 00 00 24 73 65 74 20 63 6c 69 65 6e 74 5f Q...$set client_ > 000000CA 65 6e 63 6f 64 69 6e 67 20 3d 20 27 55 4e 49 43 encoding = 'UNIC > 000000DA 4f 44 45 27 00 ODE'. > 000000DF 58 51 00 00 00 04 XQ.... > > We noticed than the 58 51 couple of bytes is unusual. It seems to > indicate a try to finish connection and then to reuse it for a query. > > We would like to know if it's a known bug of the jdbc connector for > example, or if we have a problem with our application's code (maybe doing a > close request and a query request on the same connection ?). The 7.4 driver is no longer supported, but I don't recall seeing this problem before. So it may be a driver bug, but your code is at least doing something unusual to trigger it. The tcpdump seems to show a terminate and a query message interspersed. So it's not that a terminate was issued and then a query was issuesed on a dead connection, but that the two messages are overlapping. The 7.4 driver is not threadsafe in this area, so that's the likely place to look for potential problems in your code. For a driver solution I think making org.postgresql.jdbc1.AbstractJdbc1Connection#close V3 synchronize on the pgStream object might help you out. Kris Jurka -- Sent via pgsql-jdbc mailing list (pgsql-jdbc@postgresql.org) To make changes to your Subscription: http://mail.postgresql.org/mj/mj_www...tra=pgsql-jdbc |