Estamos executando um banco de dados AWS Aurora PostgreSQL versão 13. Outro dia, eu estava tentando configurar uma tarefa de backup para ser executada a partir da réplica de leitura e acabei encontrando o erro "O usuário manteve um bloqueio de relacionamento por muito tempo". Eu trabalhei em torno disso usando a resposta nesta pergunta .
Minha pergunta é teórica e me perdoe se parece estúpida, mas estou faltando alguma coisa aqui. Se o Postgres tiver MVCC em vez de bloquear, por que o pg_dump se preocuparia com o fato de um usuário "bloquear" outra relação? Não deveria estar apenas lendo a última versão da linha?
Trata-se de bloqueios de tabela e conflitos de replicação de streaming.
pg_dumptem que ler as tabelas, e a leitura de uma tabela requer umACCESS SHAREbloqueio na tabela. Esse bloqueio entra em conflito apenas com atividades como , ,DROP TABLEeTRUNCATEcertas variantes de . Um bloqueio não bloqueia gravadores, mas evita que sessões simultâneas excluam o arquivo de dados que você está lendo no momento.CLUSTERVACUUM (FULL)ALTER TABLEACCESS SHAREAgora, se você tiver uma consulta de longa duração, como
pg_dumpno modo de espera, e alguémTRUNCATEestiver em uma tabela no primário, o PostgreSQL tentará reproduzir a instrução e oACCESS EXCLUSIVEbloqueio associado no modo de espera. Isso entrará em conflito com a consulta de longa execução e, sepg_dumpnão for feito apósmax_standby_streaming_delaya aprovação, a consulta será cancelada epg_dumpterminará com um erro.Observe que o conflito não precisa ser com uma das afirmações acima: se o autovacuum processar uma tabela no primário e as últimas páginas da tabela ficarem vazias,
VACUUMtentará remover essas páginas, o que também requer um breveACCESS EXCLUSIVEbloqueio no mesa. Isso não interrompe o processamento no primário, mas pode fazer com que as consultas sejam canceladas no modo de espera.Defina
max_standby_streaming_delaycomo -1 no servidor em espera para evitar o problema.Aqui está um artigo que trata do problema com mais detalhes.