Início / dba / Perguntas / 199994
Accepted
ffflabs
Asked: 2018-03-13 07:34:49 +0800 CST

O que acontece se dois processos tentarem ATUALIZAR A VISUALIZAÇÃO MATERIALIZADA CONCORRENTEMENTE ao mesmo tempo?

  • 772

De acordo com os documentos:

CONCORRENTEMENTE Atualize a visualização materializada sem bloquear seleções simultâneas na visualização materializada. (...)

... OUTROS CONTEÚDOS ...

Mesmo com esta opção, apenas um REFRESH de cada vez pode ser executado em qualquer visualização materializada .

Eu tinha uma função que verificava o tempo da última atualização para uma MATERIALIZED VIEW e, se tivessem passado mais de 60 segundos, seria para atualizá-la.

No entanto, o que aconteceria se eu tentasse atualizar uma visão materializada de dois processos separados ao mesmo tempo? eles enfileirariam ou gerariam um erro?

Existe uma maneira de detectar quando uma MATERIALIZED VIEW está sendo atualizada e, portanto, evitar tocá-la?

Atualmente, recorri a preencher um registro de tabela antes de atualizar (definir refreshingcomo true) e, em seguida, defini-lo para falsequando o processo for concluído.

EXECUTE 'INSERT INTO refresh_status (last_update, refreshing) 
         VALUES (clock_timestamp(), true) RETURNING id') INTO refresh_id;
EXECUTE 'REFRESH MATERIALIZED VIEW CONCURRENTLY my_mat_view';
EXECUTE 'UPDATE refresh_status SET refreshing=false WHERE id=$1' USING refresh_id;

Então, sempre que chamo esse procedimento, verifico o mais recente last_updatee seu refreshingvalor. Se refreshingfor true, não tente atualizar a visualização materializada.

EXECUTE 'SELECT 
           extract(epoch FROM now() - (last_update))::integer, 
           refreshing
         FROM refresh_status
         ORDER BY last_update DESC
         LIMIT 1' INTO update_seconds_ago, refreshing;

IF(updated_seconds_ago > 60 AND refreshing = FALSE) THEN
  -- the refresh block above
END IF;

No entanto, não tenho certeza se o sinalizador de atualização está sendo atualizado de forma síncrona (quer dizer, ele realmente espera que a atualização seja realmente concluída)

Essa abordagem é racional ou estou perdendo alguma coisa aqui?

postgresql plpgsql

3 respostas

  1. Best Answer

    Como mencionado nesta resposta , " REFRESH MATERIALIZED VIEW CONCURRENTLYpega um EXCLUSIVEbloqueio" na mesa. Seguindo a trilha de migalhas para a documentação , podemos ler que um EXCLUSIVEbloqueio em uma tabela "permite apenas ACCESS SHAREbloqueios simultâneos, ou seja, apenas leituras da tabela podem prosseguir". No mesmo parágrafo podemos ver que " EXCLUSIVEconflita com ... EXCLUSIVE", significando que outra REFRESH MATERIALIZED VIEW CONCURRENTLYinstrução, que solicita o mesmo EXCLUSIVEbloqueio, terá que esperar até que o EXCLUSIVEbloqueio anterior seja liberado.

    Se você quiser evitar esperar por esse bloqueio por um período indefinido, você pode querer definir a variável de sessãolock_timeout para um valor sensato.

    • 16

  2. Conforme observado por mustaccio , essa questão se sobrepõe significativamente aos bloqueios de exibição materializados de atualização do Postgres .

    No entanto, embora a resposta aceita para essa pergunta tenha um link que responda a essa, a resposta a essa pergunta não está diretamente incluída nessa.

    Então, para ser específico: De acordo com a página de manual do PostgreSQL sobre bloqueio explícito (o link é para a página da versão atual, para o PostGres 10), REFRESH MATERIALIZED VIEW CONCURRENTLYleva um EXCLUSIVEbloqueio. O EXCLUSIVEbloqueio parece bloquear todos os outros bloqueios, exceto ACCESS SHARE - que inclui outros EXCLUSIVEbloqueios.

    Assim, uma segunda REFRESH MATERIALIZED VIEW CONCURRENTLYrequisição na mesma view irá aguardar a liberação do lock obtido pela primeira.

    • 4

  3. Graças às respostas de mustaccio e RDFozz , finalmente entendi que REFRESH ... CONCURRENTLYfazer um bloqueio exclusivo é o motivo pelo qual a documentação do PostgreSQL diz :

    Mesmo com esta opção, apenas um REFRESH de cada vez pode ser executado em qualquer visualização materializada .

    Eu estava com medo de que isso significasse que qualquer tentativa de fazer uma atualização simultânea geraria um erro , mas à luz de suas respostas, não há nenhum erro especial envolvido. É apenas uma questão de bloqueios que enfileirarão tentativas simultâneas. Portanto, a documentação poderia ser interpretada como:

    O bloqueio adquirido durante esta operação impedirá qualquer operação que não seja a leitura da MATERIALIZED VIEW. Outras tentativas de atualizar a Visualização Materializada enquanto um REFRESH ... CONCURRENTLY estiver em execução ficarão na fila até que o primeiro bloqueio seja liberado.

    • 0

relate perguntas