BUG #12538: Transação concorrente
От | rafael.faria@linx.com.br |
---|---|
Тема | BUG #12538: Transação concorrente |
Дата | |
Msg-id | 20150113233751.2504.81691@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #12538: Transação concorrente
|
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 12538 Logged by: Rafael Faria Email address: rafael.faria@linx.com.br PostgreSQL version: 9.4.0 Operating system: Windows Description: Sou analista/desenvolvedor de um sistema em python que executa um banco postgres, e nosso sistema possui homologação apenas para a versão 8.4, porém temos clientes executando sem problemas até a versão 9.0, porém qualquer versão acima desta é impossível de usar visto que em muitas rotinas do sistema é gerado o erro abaixo. Traceback (most recent call last): File "classe/base.py", line 318, in update File "C:\python22\lib\site-packages\lzt\lztdb.py", line 534, in execute ProgrammingError: ERROR: could not serialize access due to read/write dependencies among transactions Este erro não ocorria para versões menores que a 9.1, verifiquei que vocês realizaram alterações na questão de como o banco trabalha com a questão de transações, verifiquei a documentação http://www.postgresql.org/docs/9.4/static/transaction-iso.html Também verifiquei que foi criada uma variável chamada max_pred_locks_per_transaction e tentei mudar ela para ver se meu problema resolvia, porém não consegui alterar a forma do banco trabalhar com as transações como ocorria antes. Vocês conseguem me ajudar a solucionar este problema, é possível mudar a configuração para o banco voltar a funcionar como funcionava em versões anteriores, ou é um bug do banco ou temos que alterar a nossa forma de conexão no banco como também a forma de controle de sessões. Realizei testes em versões: 8.3 = ok 8.4 = ok 9.0 = ok 9.1 = erro 9.2 = erro 9.3 = erro 9.4 = erro Aguardo retorno de vocês o quanto antes, visto que estou com um grande projeto de migração de infra para a versão 9.4 parado devido a este erro.
В списке pgsql-bugs по дате отправления: