Leandro, > Sei que não é a resposta esperada, mas a verdade a vezes doí, deadlock é > problema de lógica da aplicação.
Essa regra tem exceção. > Você pode ter milhares de transações em > paralelo e não ter deadlock, Teu sistema e tua modelagem precisam ser radicalmente simplórios para isso acontecer. > Para resolver problemas deadlock não é necessário > sacrificar paralelismo Depende do número de tabelas envolvidas nas suas transações e no número de transações diferentes que você tem na sua aplicação. É fácil evitar deadlocks se todas as telas do seu sistema sempre gravam nas mesmas tabelas, porém este caso é trivial demais para servir para o mundo real. > e sim rever a lógica de aquisição de locks da aplicação. Como já disse, posso até rever a lógica e colocar alguns LOCKs estratégicos para garantir a inexistência de deadlocks, porém isso afetará sim, e muito, a capacidade de paralelismo do servidor. E afetará de forma tão significativa que compensa ter um trabalho *enorme* cuidando dos erros e problemas gerados pelos raros casos em que deadlocks ocorrem atualmente. > Uma dica simples é adquirir os locks nos objetos sempre na mesma ordem. Esta solução simplória é excelente como regra geral, porém insuficiente para todos os casos práticos. > Para defender o postgresql posso ter informar que por exemplo o bancos > de dados bam-bam do mercado (Oracle) não tem comando similar a este e > isto não é um problema. Problemas com deadlocks sempre podem ser mitigados superdimensionando o servidor, como é comum em instalações Oracle. Isto nem de longe quer dizer que o Oracle também não se beneficiaria com isso, nem que ele está livre das mazelas dos deadlocks, especialmente para as almas penadas que pensavam que podiam usar os bitmap indexes dele sem ter problemas com deadlocks, por mais bem feita e planejada que seja sua aplicação. Esta "decisão técnica" não é a primeira péssima idéia do Oracle nem de longe a única, e a última coisa que o Postgres precisa fazer como produto é imitar os erros dos seus concorrentes, especialmente quando existem benefícios concretos como desempenho e simplicidade de projeto. Para quem quer ser melhor que seus concorrentes, fica a solicitação de inclusão dessa funcionalidade. Mozart Hasse _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
