PSQLException: transação atual é abortada, comandos ignorados até o final do bloco da transação

Estou vendo o seguinte rastreamento de pilha (truncado) no arquivo server.log do 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

A inspeção do arquivo de log do Postgres revela as seguintes instruções:

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

Estou usando o Infinispan enviado com o JBoss 7.1.1 Final, que é 5.1.2.Final.

Então é isso que eu acho que está acontecendo:

• O Infinispan tenta executar a SELECT count(*)...instrução para ver se há algum registro no ISPN_MIXED_BINARY_TABLE_configCache;
• O Postgres, por algum motivo, não gosta desta declaração.
• O Infinispan ignora isso e avança com a CREATE TABLEdeclaração.
• O Postgres vomita porque ainda pensa que é a mesma transação, que o Infinispan não conseguiu reverter, e essa transação é derivada da primeira SELECT count(*)...instrução.

O que esse erro significa e alguma idéia de como contorná-lo?

Eu recebi esse erro usando Java e postgresql fazendo uma inserção em uma tabela. Ilustrarei como você pode reproduzir este erro:

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

Resumo:

O motivo para você obter esse erro é porque você inseriu uma transação e uma das suas Consultas SQL falhou, e você engoliu a falha e a ignorou. Mas isso não foi suficiente, então você usou a mesma conexão, usando a mesma transação para executar outra consulta. A exceção é lançada na segunda consulta formada corretamente, porque você está usando uma transação quebrada para realizar trabalho adicional. O Postgresql, por padrão, impede você de fazer isso.

Estou a usar: 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".

Meu driver do postgresql é: postgresql-9.2-1000.jdbc4.jar

Usando a versão java: Java 1.7

Aqui está a instrução create da tabela para ilustrar a exceção:

CREATE TABLE moobar
(
    myval   INT
);

O programa Java causa o erro:

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();
    }   

}

O código acima produz esta saída para mim:

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

Soluções alternativas:

Você tem poucas opções:

1. Solução mais simples: não esteja em uma transação. Defina connection.setAutoCommit(false);como connection.setAutoCommit(true);. Funciona porque o SQL com falha é apenas ignorado como uma instrução sql com falha. Você pode falhar nas instruções sql o quanto quiser e o postgresql não irá impedi-lo.

2. Continue sendo uma transação, mas quando detectar que o primeiro sql falhou, reverter / reiniciar ou confirmar / reiniciar a transação. Em seguida, você pode continuar falhando quantas consultas sql nessa conexão com o banco de dados desejar.

3. Não pegue e ignore a exceção lançada quando uma instrução sql falha. Em seguida, o programa será interrompido na consulta incorreta.

4. Em vez disso, adquira o Oracle. O Oracle não lança uma exceção quando você falha em uma consulta em uma conexão em uma transação e continua usando essa conexão.

Em defesa da decisão do postgresql de fazer as coisas desta maneira ... A Oracle estava deixando você mole no meio, deixando você fazer coisas idiotas e ignorando isso.

Verifique a saída antes da declaração que causou current transaction is aborted. Isso normalmente significa que o banco de dados lançou uma exceção que seu código ignorou e agora espera que as próximas consultas retornem alguns dados.

Portanto, agora você tem uma incompatibilidade de estado entre seu aplicativo, que considera as coisas boas e o banco de dados, que exige que você reverta e reinicie sua transação desde o início.

Você deve capturar todas as exceções e transações de reversão nesses casos.

Aqui está uma questão semelhante.

Eu acho que a melhor solução é usar java.sql.Savepoint.

Antes de executar a consulta que pode lançar o SQLException, use o método Connection.setSavepoint () e, se a exceção for lançada, você reverterá somente para esse ponto de salvamento, e não reverterá todas as transações.

Código de exemplo:

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) {}

   }
}

Houve algum trabalho realizado no driver JDBC do postgresql, relacionado a esse comportamento:
consulte https://github.com/pgjdbc/pgjdbc/pull/477

Agora é possível, definindo

gravação automática = sempre

No Ruby on Rails PG, criei uma migração, migrei meu banco de dados, mas esqueci de reiniciar meu servidor de desenvolvimento. Eu reiniciei meu servidor e funcionou.

A razão para esse erro é que há outro banco de dados antes que a operação incorreta que leva à operação atual do banco de dados não possa ser realizada (eu uso a tradução do google para traduzir meu chinês para inglês)

O problema foi corrigido no Infinispan 5.1.5.CR1: ISPN-2023

Você precisa reverter. O driver do JDBC Postgres é muito ruim. Mas se você deseja manter sua transação e reverter esse erro, pode usar pontos de salvamento:

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

Leia mais aqui:

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

Eu tive o mesmo problema, mas percebi que há uma tabela com o mesmo nome no banco de dados. Depois de excluir, consegui importar o arquivo.

Esse é um comportamento muito estranho do PostgreSQL; ele não está "alinhado com a filosofia do PostgreSQL de forçar o usuário a tornar tudo explícito" - como a exceção foi capturada e ignorada explicitamente. Portanto, mesmo essa defesa não se sustenta. A Oracle, nesse caso, se comporta muito mais amigável e (quanto a mim) corretamente - deixa uma opção para o desenvolvedor.

Isso pode acontecer se você estiver sem espaço em disco no volume.

Acabei de encontrar o mesmo erro. Consegui descobrir a causa raiz ativando as informações log_statement e log_min_error_statement no PostgreSQL local.

Eu indiquei isso

Estou usando o JDBI com o Postgres e encontrei o mesmo problema, ou seja, após uma violação de alguma restrição de uma declaração de transação anterior, as instruções subsequentes falhariam (mas depois de esperar um pouco, digamos 20 a 30 segundos, o problema desaparece )

Após algumas pesquisas, descobri que o problema era fazer transações "manualmente" no meu JDBI, ou seja, cercava minhas declarações com BEGIN; ... COMMIT; e acaba por ser o culpado!

No JDBI v2, posso apenas adicionar a anotação @Transaction, e as instruções em @SqlQuery ou @SqlUpdate serão executadas como uma transação, e o problema acima mencionado não ocorrerá mais!

No meu caso, eu estava recebendo esse erro porque meu arquivo estava corrompido. Enquanto iterava os registros dos arquivos, estava me dando o mesmo erro.

Pode ser que no futuro ajude a alguém. Essa é a única razão para postar esta resposta.

Uso spring com @Transactionalanotação e pego a exceção e, por alguma exceção, tentarei novamente 3 vezes.

Para posgresql, quando há exceção, você não pode usar a mesma conexão para confirmar mais. Você deve reverter primeiro.

No meu caso, uso o DatasourceUtilspara obter a conexão atual e ligar connection.rollback()manualmente. E a chamada de método recrutar para tentar novamente.

Eu estava trabalhando com o jpa de inicialização por mola e corrigido implementando @EnableTransactionManagement

O arquivo anexado pode ajudá-lo.

Eu estava trabalhando com o jpa de inicialização por mola e corrigido implementando @EnableTransactionManagement

O arquivo anexado pode ajudá-lo.

Tente isto COMMIT;

Eu corro isso no pgadmin4. Isso pode ajudar. Tem a ver com o comando anterior parar prematuramente

Altere o nível de isolamento de leitura repetível para leitura confirmada.

Defina conn.setAutoCommit (false) como conn.setAutoCommit (true)

Confirme as transações antes de iniciar uma nova.