postgresql - linea - PSQLException: la transacción actual se cancela, los comandos se ignoran hasta el final del bloque de transacción

linea de comandos postgresql

Question

Estoy viendo el siguiente stacktrace (truncado) en el archivo server.log de JBoss 7.1.1 Final:

Caused by: org.postgresql.util.PSQLException:
ERROR: current transaction is aborted, commands ignored until end of
transaction block
at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2102)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1835)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:257)
at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:512)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:374)
at org.postgresql.jdbc2.AbstractJdbc2Statement.executeUpdate(AbstractJdbc2Statement.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [rt.jar:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [rt.jar:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:597) [rt.jar:1.6.0_23]
at org.postgresql.ds.jdbc23.AbstractJdbc23PooledConnection$StatementHandler.invoke(AbstractJdbc23PooledConnection.java:455)
at $Proxy49.executeUpdate(Unknown Source) at org.jboss.jca.adapters.jdbc.WrappedStatement.executeUpdate(WrappedStatement.java:371)
at org.infinispan.loaders.jdbc.TableManipulation.executeUpdateSql(TableManipulation.java:154) [infinispan-cachestore-jdbc-5.1.2.FINAL.jar:5.1.2.FINAL]
... 154 more

La inspección del archivo de registro de Postgres revela las siguientes afirmaciones:

STATEMENT: SELECT count(*) FROM ISPN_MIXED_BINARY_TABLE_configCache
ERROR: current transaction is aborted, commands ignored until end of transaction block
STATEMENT: CREATE TABLE ISPN_MIXED_BINARY_TABLE_configCache(ID_COLUMN VARCHAR(255) NOT NULL, DATA_COLUMN BYTEA, TIMESTAMP_COLUMN BIGINT, PRIMARY KEY (ID_COLUMN))
ERROR: relation "ispn_mixed_binary_table_configcache" does not exist at character 22

Estoy usando el Infinispan enviado con JBoss 7.1.1 Final, que es 5.1.2.Final.

Entonces esto es lo que creo que está sucediendo:

• Infinispan intenta ejecutar la SELECT count(*)... para ver si hay registros en ISPN_MIXED_BINARY_TABLE_configCache ;
• A Postgres, por alguna razón, no le gusta esta afirmación.
• Infinispan ignora esto y sigue adelante con la instrucción CREATE TABLE .
• Postgres barfs porque aún cree que es la misma transacción, que Infinispan no ha podido revertir, y esta transacción se deriva de la primera SELECT count(*)...

¿Qué significa este error y alguna idea de cómo solucionarlo?

Answer 1

Acabo de encontrar el mismo error. Pude averiguar la causa raíz al habilitar log_statement y log_min_error_statement en mi PostgreSQL local.

Me refirió esto

Answer 2

Cambie el nivel de aislamiento de lectura repetible a lectura confirmada.

Answer 3

Creo que la mejor solución es usar java.sql.Savepoint.

Antes de ejecutar la consulta que puede arrojar SQLException, use el método Connection.setSavepoint () y, si se produce una excepción, solo retrotraerá a este punto de rescate y no revertirá todas las transacciones.

Código de ejemplo:

Connection conn = null;
Savepoint savepoint = null;
try {
conn = getConnection();
savepoint = conn.setSavepoint();
//execute some query
} catch(SQLException e) {
if(conn != null && savepoint != null) {
conn.rollback(savepoint);
}
} finally {
if(conn != null) {
try {
conn.close();
} catch(SQLException e) {}
}
}

Answer 4

El problema se ha solucionado en Infinispan 5.1.5.CR1: ISPN-2023

Answer 5

En Ruby on Rails PG, creé una migración, migré mi base de datos, pero olvidé reiniciar mi servidor de desarrollo. Reinicié mi servidor y funcionó.

Answer 6

Este es un comportamiento muy extraño de PostgreSQL, incluso no está "en línea con la filosofía de PostgreSQL de forzar al usuario a hacer que todo sea explícito", ya que la excepción fue capturada e ignorada explícitamente. Entonces incluso esta defensa no se sostiene. En este caso, Oracle se comporta de manera mucho más amigable y (en mi caso) correctamente, deja una elección al desarrollador.

Answer 7

Esto puede suceder si se queda sin espacio en disco en el volumen.

Answer 8

Estoy usando JDBI con Postgres, y encontré el mismo problema, es decir, después de una violación de alguna restricción de una declaración de una transacción anterior, las declaraciones posteriores fallarían (pero después de esperar un tiempo, digamos 20-30 segundos, el problema desaparece )

Después de algunas investigaciones, encontré que el problema era que estaba haciendo transacciones "manualmente" en mi JDBI, es decir, rodeé mis declaraciones con BEGIN; ... COMMIT; y resulta ser el culpable!

En JDBI v2, puedo simplemente agregar la anotación @Transaction, y las declaraciones dentro de @SqlQuery o @SqlUpdate se ejecutarán como una transacción, ¡y el problema mencionado anteriormente ya no ocurre!

Answer 9

La razón de este error es que hay otra base de datos antes de que la operación incorrecta condujera a que la operación actual de la base de datos no pueda llevarse a cabo (yo uso la traducción de google para traducir mi chino al inglés)

Answer 10

Necesitas retroceder. El controlador JDBC Postgres es bastante malo. Pero si desea mantener su transacción y simplemente deshacer ese error, puede usar savepoints:

try {
_stmt = connection.createStatement();
_savePoint = connection.setSavepoint("sp01");
_result = _stmt.executeUpdate(sentence) > 0;
} catch (Exception e){
if (_savePoint!=null){
connection.rollback(_savePoint);
}
}

Leer más aquí:

http://www.postgresql.org/docs/8.1/static/sql-savepoint.html

Answer 11

Se ha realizado un trabajo sobre el controlador JDBC postgresql, relacionado con este comportamiento:
ver https://github.com/pgjdbc/pgjdbc/pull/477

Ahora es posible, al establecer

autosave=always en la conexión (ver https://jdbc.postgresql.org/documentation/head/connect.html ) para evitar el síndrome de ''transacción actual ha abortado''.
Los gastos generales debido a la administración de un punto de rescate en torno a la ejecución de la declaración se mantienen muy bajos (consulte el enlace anterior para obtener más información).

Answer 12

Tuve el mismo problema pero luego me di cuenta de que hay una tabla con el mismo nombre en la base de datos. Después de eliminar que pude importar el archivo.

Answer 13

Verifique el resultado antes de que se anule la declaración que causó current transaction is aborted . Esto normalmente significa que la base de datos lanzó una excepción que su código había ignorado y ahora espera que las próximas consultas devuelvan algunos datos.

Por lo tanto, ahora tiene una discrepancia de estado entre su aplicación, que considera que todo está bien, y la base de datos, que requiere que reinicie y reinicie su transacción desde el principio.

Debería detectar todas las excepciones y transacciones de reversión en tales casos.

Aquí hay un problema similar.

Answer 14

Obtuve este error usando Java y postgresql haciendo una inserción en una tabla. Ilustraré cómo puedes reproducir este error:

org.postgresql.util.PSQLException: ERROR:
current transaction is aborted, commands ignored until end of transaction block

Resumen:

La razón por la que obtienes este error es porque has ingresado una transacción y una de tus Consultas SQL falló, y engulliste esa falla y la ignoraste. Pero eso no fue suficiente, ENTONCES usaste esa misma conexión, usando la MISMA TRANSACCIÓN para ejecutar otra consulta. La excepción se aplica a la segunda consulta, formada correctamente, porque está utilizando una transacción interrumpida para realizar un trabajo adicional. Postgresql por defecto te impide hacer esto.

Estoy usando: PostgreSQL 9.1.6 on x86_64-redhat-linux-gnu, compiled by gcc (GCC) 4.7.2 20120921 (Red Hat 4.7.2-2), 64-bit".

Mi controlador postgresql es: postgresql-9.2-1000.jdbc4.jar

Usando la versión de Java 1.7 : Java 1.7

Aquí está la declaración de creación de tabla para ilustrar la excepción:

CREATE TABLE moobar
(
myval INT
);

El programa Java causa el error:

public void postgresql_insert()
{
try
{
connection.setAutoCommit(false); //start of transaction.
Statement statement = connection.createStatement();
System.out.println("start doing statement.execute");
statement.execute(
"insert into moobar values(" +
"''this sql statement fails, and it " +
"is gobbled up by the catch, okfine''); ");
//The above line throws an exception because we try to cram
//A string into an Int. I Expect this, what happens is we gobble
//the Exception and ignore it like nothing is wrong.
//But remember, we are in a TRANSACTION! so keep reading.
System.out.println("statement.execute done");
statement.close();
}
catch (SQLException sqle)
{
System.out.println("keep on truckin, keep using " +
"the last connection because what could go wrong?");
}
try{
Statement statement = connection.createStatement();
statement.executeQuery("select * from moobar");
//This SQL is correctly formed, yet it throws the
//''transaction is aborted'' SQL Exception, why? Because:
//A. you were in a transaction.
//B. You ran a sql statement that failed.
//C. You didn''t do a rollback or commit on the affected connection.
}
catch (SQLException sqle)
{
sqle.printStackTrace();
}
}

El código anterior produce esta salida para mí:

start doing statement.execute
keep on truckin, keep using the last connection because what could go wrong?
org.postgresql.util.PSQLException:
ERROR: current transaction is aborted, commands ignored until
end of transaction block

Soluciones:

Tienes pocas opciones:

1. La solución más simple: no estar en una transacción. Establezca connection.setAutoCommit(false); a connection.setAutoCommit(true); . Funciona porque el SQL fallido simplemente se ignora como una declaración sql fallida. Le invitamos a fallar sentencias sql todo lo que desee y postgresql no lo detendrá.

2. Permanezca en una transacción, pero cuando detecte que el primer sql ha fallado, revertir / reiniciar o confirmar / reiniciar la transacción. Entonces puede continuar fallando tantas consultas sql en esa conexión de base de datos como desee.

3. No atrape e ignore la excepción que se lanza cuando falla una instrucción sql. Entonces el programa se detendrá en la consulta mal formada.

4. Obtenga Oracle en su lugar, Oracle no lanza una excepción cuando falla una consulta en una conexión dentro de una transacción y continúa usando esa conexión.

En defensa de la decisión de Postgresql de hacer las cosas de esta manera ... Oracle te estaba haciendo blando en el medio, permitiéndote hacer cosas tontas y pasarlas por alto.