[BUGS] BUG #4637: FATAL: sorry, too many clients already
The following bug has been logged online: Bug reference: 4637 Logged by: chetan Email address: cheth...@inat.in PostgreSQL version: plus 8.3 Operating system: windows xp Description:FATAL: sorry, too many clients already Details: 2009-02-03 12:41:58,109 INFO [STDOUT] 12:41:58,109 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 53300 2009-02-03 12:41:58,109 INFO [STDOUT] 12:41:58,109 ERROR [JDBCExceptionReporter] FATAL: sorry, too many clients already 2009-02-03 12:41:58,109 ERROR [STDERR] org.hibernate.exception.GenericJDBCException: Cannot open connection at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLSta teConverter.java:103) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:91) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java :43) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java :29) at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:4 26) at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:14 4) at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:119) at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:57) at org.hibernate.impl.SessionImpl.beginTransaction(SessionImpl.java:1326) at in.inat.educateIT.department.action.Predepartment.execute(Predepartment.java :62) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionIn vocation.java:404) at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActi onInvocation.java:267) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocati on.java:229) at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(D efaultWorkflowInterceptor.java:221) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(Method FilterInterceptor.java:86) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:224) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:223) at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack .java:455) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocati on.java:221) at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(Validati onInterceptor.java:150) at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.do Intercept(AnnotationValidationInterceptor.java:48) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(Method FilterInterceptor.java:86) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:224) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:223) at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack .java:455) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocati on.java:221) at com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(Con versionErrorInterceptor.java:123) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:224) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:223) at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack .java:455) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocati on.java:221) at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(Parame tersInterceptor.java:167) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(Method FilterInterceptor.java:86) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:224) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:223) at com.opensymphony.xwork2.util.profiling.UtilTimerStack.profile(UtilTimerStack .java:455) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocati on.java:221) at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(St aticParametersInterceptor.java:105) at com.opensymphony.xwork2.DefaultActionInvocation$2.doProfiling(DefaultActionI nvocation.java:224)
[BUGS] BUG #4638: Bug with Geometry in Array
The following bug has been logged online:
Bug reference: 4638
Logged by: Bjoern Weitzig
Email address: weit...@supportgis.de
PostgreSQL version: 8.3.5
Operating system: Windows
Description:Bug with Geometry in Array
Details:
System: PostgreSQL 8.3.5, compiled by Visual C++ build 1400
(Windows-Installer), PostGIS 1.3.5, GEOS 3.0.3-CAPI-1.4.2 on Windows
I use arrays like "select array(select n from a)". This works well except of
the case with geometry as datatype.
In case of geometry, the JDBC ResultSet.getArray(1).getResultSet() only
lists the first element.
Testcase:
create table a(n VARCHAR);
SELECT AddGeometryColumn( 'a', 'feature', -1, 'GEOMETRY', 3 );
INSERT INTO a(n, feature) VALUES (1,GeomFromText('Point(1 1 0)',-1));
INSERT INTO a(n, feature) VALUES (2,GeomFromText('Point(2 2 0)',-1));
select array(select n from a);
=> "{1,2}" (ok)
select array(select feature from a);
=>
"{010180F03FF03F:0101800
0400040}"
I wonder why there is a ":" instead of an ",".
JDBC:
ResultSet rset = stmt.executeQuery("select array(select feature
from
a)");
if (rset.next()) {
Array array = rset.getArray(1);
ResultSet rs2 = array.getResultSet();
int n=0;
while (rs2.next()) {
Object o = rs2.getObject(2);
n++;
System.out.println(n+": "+o);
}
rs2.close();
}
This lists only the first point "1: POINT(1 1 0)", instead of expected "1:
POINT(1 1 0) \n 2: POINT(2 2 0)"
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] BUG #4638: Bug with Geometry in Array
"Bjoern Weitzig" writes: > I use arrays like "select array(select n from a)". This works well except of > the case with geometry as datatype. The geometry type intentionally uses ':' as the array delimiter. It seems like a good bet that the JDBC driver you're using doesn't expect anything but ',' as array delimiter. I checked with the postgis-devel list and they recommend using the modified JDBC driver that's distributed with postgis. http://postgis.refractions.net/documentation/manual-1.3.6SVN/ch04.html#id2726248 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
Re: [BUGS] BUG #4637: FATAL: sorry, too many clients already
chetan wrote: The following bug has been logged online: Bug reference: 4637 Logged by: chetan Email address: cheth...@inat.in PostgreSQL version: plus 8.3 Operating system: windows xp Description:FATAL: sorry, too many clients already Details: 2009-02-03 12:41:58,109 INFO [STDOUT] 12:41:58,109 WARN [JDBCExceptionReporter] SQL Error: 0, SQLState: 53300 2009-02-03 12:41:58,109 INFO [STDOUT] 12:41:58,109 ERROR [JDBCExceptionReporter] FATAL: sorry, too many clients already 2009-02-03 12:41:58,109 ERROR [STDERR] [...] This is not a bug - you simple hit the maximum limit of allowed clients set in postgresql.conf. If you want to create more connections increase the max_connections variable or look into connection pooling. Stefan -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] pg_listener entries deleted under heavy NOTIFY load only on Windows
I've completed my test for changes to the Windows implementation of
pgkill. I ran two clients constantly doing a pair of notifications,
with one client subscribing to those events. I ran the test for 90
hours. I found 760 cases where the CallNamedPipe function initially
failed, but succeeded after recalling. In all but one of those cases,
only a single retry was needed; the other case required two retries.
As Tom has pointed out, there is no principled way to determine the
correct number of times to retry. Therefore, I have set the maximum
number of retries to 2, which is the worst case found in a fairly long
stress test. This strikes me as a reasonable balance between failing
quickly in truly erroneous cases, while still avoiding transient
pseudo-failures.
A patch with this change is attached. It should be applied to the
8.3.5 version of src/port/kill.c
Steve
*** kill.c 2009-02-03 14:28:21.753474644 -0500
--- kill.c.mod 2009-02-03 14:28:04.465829331 -0500
***
*** 25,30
--- 25,33
BYTEsigData = sig;
BYTEsigRet = 0;
DWORD bytes;
+ DWORD timeout = 1000; /* in ms; forever =
NMPWAIT_WAIT_FOREVER */
+ const int max_pipe_tries = 3;
+ int pipe_tries = 0;
/* we allow signal 0 here, but it will be ignored in pg_queue_signal */
if (sig >= PG_SIGNAL_COUNT || sig < 0)
***
*** 39,45
return -1;
}
snprintf(pipename, sizeof(pipename), ".\\pipe\\pgsignal_%u", pid);
! if (!CallNamedPipe(pipename, &sigData, 1, &sigRet, 1, &bytes, 1000))
{
if (GetLastError() == ERROR_FILE_NOT_FOUND)
errno = ESRCH;
--- 42,63
return -1;
}
snprintf(pipename, sizeof(pipename), ".\\pipe\\pgsignal_%u", pid);
!
! /*
!* Writing data to the named pipe can fail for transient reasons.
!* Therefore, it is useful to retry if it fails. The maximum number
of
!* calls to make was empirically determined from a 90-hour
notification
!* stress test.
!*/
! while (pipe_tries < max_pipe_tries &&
! !CallNamedPipe(pipename, &sigData, 1, &sigRet, 1,
&bytes, timeout))
! {
! pipe_tries++;
! timeout = 250;
! pg_usleep(1);
! }
!
! if (pipe_tries >= max_pipe_tries)
{
if (GetLastError() == ERROR_FILE_NOT_FOUND)
errno = ESRCH;
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Re: [BUGS] Behavior of identically-named savepoints
On Tue, Feb 03, 2009 at 11:31:31AM -0700, Joshua Tolley wrote: > Unless, of course, > I'm missing something. Yep, I was missing something. I didn't realize ROLLBACK TO SAVEPOINT didn't destroy the newer savepoint like RELEASE SAVEPOINT does. Adding RELEASE SAVEPOINT calls to my test script makes it work as I'd expect. Sorry for the noise. - Josh / eggyknap signature.asc Description: Digital signature
[BUGS] Behavior of identically-named savepoints
The SAVEPOINT documentation says that a new savepoint created with the same name as an existing savepoint masks but does not destroy the old savepoint, and rolling back to the savepoint will then make the old savepoint available for RELEASE SAVEPOINT and ROLLBACK TO SAVEPOINT calls. 8.3.5 and my 8.4devel (built a few days ago) don't follow this behavior, as demonstrated with the attached script. Unless, of course, I'm missing something. - Josh / eggyknap CREATE TEMPORARY TABLE test (id INTEGER); BEGIN; INSERT INTO test (id) VALUES (1); SAVEPOINT svpt; INSERT INTO test (id) VALUES (2); SAVEPOINT svpt; INSERT INTO test (id) VALUES (3); SAVEPOINT svpt; INSERT INTO test (id) VALUES (4); SAVEPOINT svpt; INSERT INTO test (id) VALUES (5); SELECT * FROM test; SELECT 'Should show values 1..5'; ROLLBACK TO SAVEPOINT svpt; SELECT * FROM test; SELECT 'Should show values 1..4'; ROLLBACK TO SAVEPOINT svpt; SELECT * FROM test; SELECT 'Per docs, should show values 1..3, but it doesn''t'; COMMIT; SELECT * FROM test; SELECT 'Per docs, should show values 1..3, but it doesn''t'; signature.asc Description: Digital signature
