configurações de sessão de materialized_views_*

Estas configurações estão disponíveis em system.settings e são geradas automaticamente a partir do código-fonte.

Se estiver habilitada, as exceções lançadas ao enviar dados para uma visão materializada dependente (no SELECT dela ou no sink da tabela interna) serão registradas como aviso, e a instrução INSERT será concluída com sucesso. Se estiver desabilitada (padrão), essa exceção será propagada, e a instrução INSERT falhará.

Essa configuração controla apenas como os erros são reportados. Ela não reverte uma gravação na tabela de origem nem garante se o bloco original já foi confirmado na tabela de origem quando ocorre um erro no pipeline de uma visão dependente. Quando desabilitada (padrão), o INSERT falha em caso de erro na visão — tente novamente com desduplicação de insert (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views) para entrega exatamente uma vez na tabela de origem e em todas as visões dependentes. Quando habilitada, o INSERT informa sucesso apesar da entrega parcial para visões com falha e suas cadeias subsequentes; use isso apenas quando as gravações na tabela de origem não puderem ser bloqueadas por problemas no lado da visão (por exemplo, tabelas system.*_log). Consulte a documentação de CREATE VIEW para ver a semântica completa.

Torna CREATE MATERIALIZED VIEW ... POPULATE atômico: a visão é inscrita para novos inserts na tabela de origem e, ao mesmo tempo, é criado um snapshot dos dados existentes, sob um breve lock exclusivo na tabela de origem, para que cada linha inserida durante o preenchimento seja entregue à visão exatamente uma vez (sem ser perdida nem duplicada). Em seguida, o preenchimento (possivelmente de longa duração) lê o snapshot fixado sem manter nenhum lock.

Trata-se de atomicidade local no caminho de insert: o lock exclusivo serializa apenas com inserts que adquirem o lock de armazenamento da tabela de origem no mesmo servidor, portanto a garantia de exatamente uma vez abrange inserts que chegam por esse servidor. Não é uma garantia para todo o cluster — linhas inseridas em outra réplica de uma origem ReplicatedMergeTree ou por meio de um caminho de gravação distribuída (por exemplo, em uma tabela Distributed ou via ON CLUSTER) durante o preenchimento ainda podem ser perdidas ou duplicadas.

Isso exige que a tabela de origem ofereça suporte à leitura de um snapshot fixado em um momento específico (a família MergeTree e Memory). Para qualquer outra origem (uma visão, Distributed, Merge, a família Log ou uma tabela que não esteja em um banco de dados Atomic), o preenchimento recorre ao comportamento legado não atômico (registrado no log do servidor): os dados existentes são lidos com um snapshot separado e não coordenado, de modo que linhas inseridas durante o preenchimento podem ser perdidas ou duplicadas. Defina esta configuração como false para forçar o comportamento legado em todas as origens. Aplica-se somente a CREATE MATERIALIZED VIEW simples; CREATE OR REPLACE / REPLACE sempre usam o preenchimento legado não atômico, assim como uma visão criada em um banco de dados Replicated (no qual POPULATE exige database_replicated_allow_heavy_create), pois não seria possível reverter de forma consistente, em todas as réplicas, um preenchimento que falhasse.

Agrupa inserts paralelos de uma única consulta INSERT na tabela de destino de visões materializadas para reduzir a quantidade de partes geradas. Se definido como false e parallel_view_processing estiver ativado, a consulta INSERT gerará uma parte na tabela de destino para cada max_insert_thread.