Estamos tendo esse comportamento estranho ExclusiveLock
em um de nossos bancos de dados executando o PostgreSQL 13. Não consigo descobrir o que leva a esse bloqueio, pois as informações de bloqueio são de uma ferramenta de monitoramento.
Pelo que vejo nos documentos ExclusiveLock
adquiridos apenas por atualização materialised view
, no entanto, não temos nenhuma visualização materializada em nosso banco de dados. Um pouco de pesquisa que acabei neste blog https://blog.heroku.com/curious-case-table-locking-update-query e o caso que esse cara compartilha é semelhante ao meu, pois posso ver alguns RowExclusiveLock
durante esse período e algumas consultas atualizando a mesma linha simultaneamente. No entanto, não consegui encontrar nenhum documento oficial sobre o comportamento do PostgreSQL na escalada de bloqueio, assim como outros bancos de dados fazem.
O Postgres escala o bloqueio em casos raros? Quais casos podem levar a escalações?
O PostgreSQL não escala bloqueios (OK, estou mentindo — bloqueios de predicado em páginas de índice são escalados para bloqueios de tabela quando o índice é descartado, mas não é isso que está acontecendo aqui). O PostgreSQL evita a necessidade de escalação de bloqueio armazenando bloqueios de linha na própria linha em vez de na tabela de bloqueio de memória compartilhada.
Se você olhar a
pg_locks
entrada mais de perto, verá que o bloqueio exclusivo não está em uma tabela, mas em uma transação. Cada transação tem um bloqueio exclusivo em seu próprio número de transação. Se uma sessão encontrar um bloqueio de linha conflitante, ela aguarda o término da transação de bloqueio, aguardando um bloqueio compartilhado no número da transação. É isso que você deve estar vendo.Talvez este artigo possa ajudar você a entender o problema.