Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
Tom Lane wrote:
Dave Cramer [EMAIL PROTECTED] writes:
This is a server bug, I will post to hackers for you, it has little
to do with JDBC, however the ? can't be a column in a prepared statement
I cannot reproduce any problem using what I think is equivalent in libpq:
I thought we got this one sorted out already, it was a server bug fixed
in beta2? At the time you said:
JEAN-PIERRE PELLETIER [EMAIL PROTECTED] writes:
08:47:19.296 (1) FE= Parse(stmt=null,query=select $1 from (select * from
pg_database) t,oids={23})
Actually, now that I look closely, this command is almost certainly
triggering this beta1 bug:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00107.php
Please try beta2 and see if it isn't fixed.
regards, tom lane
(and the problem went away in beta2)
-O
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code -1073741819, 8.2 beta1
Dave Cramer [EMAIL PROTECTED] writes: This is a server bug, I will post to hackers for you, it has little to do with JDBC, however the ? can't be a column in a prepared statement I cannot reproduce any problem using what I think is equivalent in libpq: /* Here is our out-of-line parameter value */ paramValues[0] = 1; res = PQexecParams(conn, select $1 from (select * from pg_database) t, 1,/* one param */ NULL,/* let the backend deduce param type */ paramValues, NULL,/* don't need param lengths since text */ NULL,/* default to all text params */ 0); /* ask for text results */ This comes back with ERROR: could not determine data type of parameter $1 but no crash. Is the JDBC driver doing anything interesting as a result of the pstmt.setObject(1, 1); and if so what? regards, tom lane ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
) at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11AprProcessor.process(Http11AprProcessor.java:831) at org.apache.coyote.http11.Http11AprProtocol$Http11ConnectionHandler.process(Http11AprProtocol.java:639) at org.apache.tomcat.util.net.AprEndpoint$Worker.run(AprEndpoint.java:1196) at java.lang.Thread.run(Unknown Source) SQLException: SQLState(08006) From: Oliver Jowett [EMAIL PROTECTED] To: Tom Lane [EMAIL PROTECTED] CC: Dave Cramer [EMAIL PROTECTED], JEAN-PIERRE PELLETIER [EMAIL PROTECTED], List pgsql-jdbc@postgresql.org, PostgreSQL-development pgsql-hackers@postgresql.org Subject: Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code Date: Wed, 25 Oct 2006 03:26:07 + Tom Lane wrote: NULL,/* let the backend deduce param type */ I think the JDBC driver will be passing the int4 OID for the param type in this case. Best thing is probably for the OP to run with loglevel=2 and see exactly what's being sent, though. -O ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
JEAN-PIERRE PELLETIER [EMAIL PROTECTED] writes:
08:47:19.296 (1) FE= Parse(stmt=null,query=select $1 from (select * from
pg_database) t,oids={23})
Actually, now that I look closely, this command is almost certainly
triggering this beta1 bug:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00107.php
Please try beta2 and see if it isn't fixed.
regards, tom lane
---(end of broadcast)---
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
Yes, the problem is gone in 8.2 beta2.
Thanks all for an outstanding product and support,
Jean-Pierre Pelletier
From: Tom Lane [EMAIL PROTECTED]
To: JEAN-PIERRE PELLETIER [EMAIL PROTECTED]
CC: pgsql-hackers@postgresql.org, [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit
code Date: Wed, 25 Oct 2006 10:15:03 -0400
JEAN-PIERRE PELLETIER [EMAIL PROTECTED] writes:
08:47:19.296 (1) FE= Parse(stmt=null,query=select $1 from (select *
from
pg_database) t,oids={23})
Actually, now that I look closely, this command is almost certainly
triggering this beta1 bug:
http://archives.postgresql.org/pgsql-committers/2006-10/msg00107.php
Please try beta2 and see if it isn't fixed.
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code -1073741819, 8.2 beta1
This is a server bug, I will post to hackers for you, Please provide a complete test case. I tried to reproduce the failure in libpq, with tom, i've just noticed this is the exact same error message errorcode as i get when updating a table that contains a tsearch2 vector column 2006-10-25 20:08:42 [3420] LOG: 0: server process (PID 2332) exited with exit code -1073741819 2006-10-25 20:08:42 [3420] LOCATION: LogChildExit, postmaster.c:2385 (test case provided, see Re: [BUGS] 8.2beta1 (w32): server process crash (tsvector) from oct. 17th) maybe dave is also using tsearch2 in the involved tables, or is this a general error code? regards, thomas ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code -1073741819, 8.2 beta1
This is a server bug, I will post to hackers for you, it has little to do with JDBC, however the ? can't be a column in a prepared statement DAVE On 24-Oct-06, at 4:45 PM, JEAN-PIERRE PELLETIER wrote: Hi, I have a query that throws org.postgresql.util.PSQLException: An I/ O error occured while sending to the backend. Here is a simplified version of it where I used pg_database, but any table or view do the same. PreparedStatement pstmt = connection.prepareStatement(select ? from (select * from pg_database) t); pstmt.setObject(1, 1); ResultSet rs = pstmt.executeQuery(); It restarts PostgreSQL with this in the Log 2006-10-24 15:35:38 LOG: server process (PID 1188) exited with exit code -1073741819 2006-10-24 15:35:38 LOG: terminating any other active server processes 2006-10-24 15:35:38 LOG: all server processes terminated; reinitializing 2006-10-24 15:35:39 LOG: database system was interrupted at 2006-10-24 15:34:54 Eastern Standard Time 2006-10-24 15:35:39 LOG: Windows fopen(recovery.conf,r) failed: code 2, errno 2 2006-10-24 15:35:39 LOG: Windows fopen(pg_xlog/ 0001.history,r) failed: code 2, errno 2 2006-10-24 15:35:39 LOG: Windows fopen(backup_label,r) failed: code 2, errno 2 2006-10-24 15:35:39 LOG: checkpoint record is at 0/31FDF0A0 2006-10-24 15:35:39 LOG: redo record is at 0/31FDF0A0; undo record is at 0/0; shutdown TRUE 2006-10-24 15:35:39 LOG: next transaction ID: 0/22535; next OID: 101011 2006-10-24 15:35:39 LOG: next MultiXactId: 1; next MultiXactOffset: 0 2006-10-24 15:35:39 LOG: database system was not properly shut down; automatic recovery in progress 2006-10-24 15:35:39 LOG: record with zero length at 0/31FDF0F0 2006-10-24 15:35:39 LOG: redo is not required 2006-10-24 15:35:40 LOG: database system is ready 2006-10-24 15:35:40 LOG: Windows fopen(global/pg_fsm.cache,rb) failed: code 2, errno 2 2006-10-24 15:35:40 LOG: transaction ID wrap limit is 2147484172, limited by database postgres 2006-10-24 15:36:40 LOG: Windows fopen(global/pgstat.stat,rb) failed: code 2, errno 2 2006-10-24 15:36:40 LOG: Windows fopen(global/pgstat.stat,rb) failed: code 2, errno 2 I am using PostgreSQL 8.2 beta1 on Windows XP, Service Pack 2 Both JDBC3 driver 8.1 build 407 and 8.2 build 503 do the same. Thanks, Jean-Pierre Pelletier e-djuster ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code -1073741819, 8.2 beta1
Dave Cramer [EMAIL PROTECTED] writes: This is a server bug, I will post to hackers for you, Please provide a complete test case. I tried to reproduce the failure in libpq, with /* Here is our out-of-line parameter value */ paramValues[0] = joe's place; res = PQexecParams(conn, SELECT $1 FROM (select * from pg_database) t, 1,/* one param */ NULL,/* let the backend deduce param type */ paramValues, NULL,/* don't need param lengths since text */ NULL,/* default to all text params */ 0); /* ask for text results */ and got nothing worse than SELECT failed: ERROR: could not determine data type of parameter $1 regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [JDBC] server process (PID 1188) exited with exit code
Tom Lane wrote: NULL,/* let the backend deduce param type */ I think the JDBC driver will be passing the int4 OID for the param type in this case. Best thing is probably for the OP to run with loglevel=2 and see exactly what's being sent, though. -O ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
