Estou tentando migrar nosso banco de dados PostgreSQL 9.4 do nível de transação READ COMMITTEDpara REPEATABLE READou SERIALIZABLE. Em ambos os casos, estou exposto a um novo conjunto de erros com o formato:
(for both)
ERROR: could not serialize access due to concurrent update
(just for SERIALIZABLE)
ERROR: could not serialize access due to read/write dependencies among transactions
Depois de ler a página wiki sobre SSI e os documentos , entendo completamente as condições de erro que podem causar esses erros, como lidar com eles e até mesmo as melhores práticas para evitá-los.
No entanto, não vejo como determinar a dependência de dados que os causou a partir de qualquer saída de depuração que o PostgreSQL possa fornecer ou, na verdade, de qualquer informação de depuração. Existe alguma maneira de obter essas informações do banco de dados, seja executando consultas adicionais no momento da reversão ou por meio de algum mecanismo de log?
Ter essas informações me permitiria fazer alterações no nível do aplicativo (bloqueio, consultas diferentes etc.) que eliminariam algumas corridas de dados para evitar um número excessivo de reversões.
Seria bom ter, mas não acho que haja muito no momento. É particularmente complicado porque várias instruções geralmente estão envolvidas e o(s) culpado(s) nem sempre são os que estão em execução, especialmente em falhas de confirmação. Coletar as informações extras seria prejudicial para o desempenho e o uso da memória, mas seria uma ótima opção para ativar durante a depuração.
Sua melhor aposta é provavelmente aumentar muito seus níveis de log e certificar-se de
log_line_prefixincluir%m,%p,%c:%le%v:%xassim você tem as informações de transação e sessão necessárias para identificar e remontar quais sessões e seus xacts fizeram dos logs.