Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

Cloud Postgres 9.1 slow loading of Data Type compositions.



Customer experiencing issues when opening Data Objects, such as displaying the properties of a class (the example scenario showed 2 minutes to load this Data Type).

It seems that the problem is database related, maybe indexes are missing. It's a Postgres Instance on a split schema.

Error Messages

ClientAbortException: Broken pipe

at org.apache.catalina.connector.OutputBuffer.realWriteBytes(
at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(
at org.apache.catalina.connector.OutputBuffer.doFlush(
at org.apache.catalina.connector.OutputBuffer.close(
at org.apache.catalina.connector.CoyoteOutputStream.close(
at com.pega.jcraft.jzlib.DeflaterOutputStream.close(
at sun.nio.cs.StreamEncoder.implClose(
at sun.nio.cs.StreamEncoder.close(

at java.lang.reflect.Method.invoke(
at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(
at com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(
at com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(

at javax.servlet.http.HttpServlet.service(
at javax.servlet.http.HttpServlet.service(

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(
at org.apache.catalina.core.StandardHostValve.invoke(
at org.apache.catalina.valves.ErrorReportValve.invoke(
at org.apache.catalina.valves.AccessLogValve.invoke(
at org.apache.catalina.core.StandardEngineValve.invoke(

at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$
Caused by: Broken pipe
at Method)

Steps to Reproduce

Not Listed.

Root Cause

The root cause of this problem is defect/misconfiguration in the operating environment.

In general the guardrail queries are complex. The query running slow has nothing to do with custom rule tables. It just depends on the data (number of rules in the system and the number of warnings for all these rules).

Note that if the data is of reasonable size and the statistics on the tables are up to date, they don't take long and it should get the required data in less than 2 seconds.

In 7.1.6, schema changes were introduced to make these queries execute faster. These schema changes include two new columns in the table pr4_rule_vw table in the rules schema.

The population of data in pr4_rule_vw table happens through database triggers defined for each rule table shipped. Since frameworks and customers can have their own rule types mapped to a table which is not shipped out of the box by PRPC, we cannot leverage this performance benefit in those scenarios unless they make the same modifications to their rule table triggers which we have done for ours. Thus, the prconfig setting mentioned below is therefore disabled by default.


This issue is resolved through the following local change:

The Team changed the parameter:

reporting/useLayerCakeSchemaChanges in prconfig.xml to true and restarted.

Published June 12, 2015 - Updated October 8, 2020

Was this useful?

0% found this useful

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us