These settings are available in system.settings and are autogenerated from source.
materialized_views_ignore_errors
If enabled, exceptions thrown while pushing data to a dependent materialized view (in its SELECT or in the inner table sink) are logged as a warning and the INSERT statement succeeds. If disabled (default), such an exception propagates and the INSERT statement fails.
This setting controls only error reporting. It does not roll back a write to the source table, and it does not guarantee whether the original block has already been committed to the source table when an error occurs in a dependent view’s pipeline. When disabled (default), the INSERT fails on a view error — retry it with insert deduplication (insert_deduplicate, deduplicate_blocks_in_dependent_materialized_views) for exactly-once delivery to the source table and all dependent views. When enabled, the INSERT reports success despite partial delivery to failing views and their downstream chains; use this only when source-table writes must not be blocked by view-side problems (for example, system.*_log tables). See the CREATE VIEW docs for full semantics.
materialized_views_populate_atomically
Make CREATE MATERIALIZED VIEW ... POPULATE atomic: the view is subscribed to new inserts of the source table and a snapshot of the existing data is taken together, under a brief exclusive lock on the source table, so that every row inserted concurrently with the population is delivered to the view exactly once (neither missed nor duplicated). The (possibly long-running) population then reads the pinned snapshot without holding any lock.
This is local insert-path atomicity: the exclusive lock only serializes with inserts that acquire this source table’s storage lock on the same server, so the exactly-once guarantee covers inserts arriving through this server. It is not a cluster-wide guarantee - rows inserted on another replica of a ReplicatedMergeTree source, or through a distributed write path (for example, into a Distributed table or via ON CLUSTER), concurrently with the population can still be missed or duplicated.
This requires the source table to support reading a pinned point-in-time snapshot (the MergeTree family and Memory). For any other source (a view, Distributed, Merge, the Log family, or a table not in an Atomic database) the population falls back to the legacy, non-atomic behavior (recorded in the server log): existing data is read with a separate, non-coordinated snapshot, so rows inserted during the population can be missed or duplicated. Set this setting to false to force the legacy behavior for all sources. Applies to plain CREATE MATERIALIZED VIEW only; CREATE OR REPLACE / REPLACE always use the legacy non-atomic population, and so does a view created in a Replicated database (where POPULATE requires database_replicated_allow_heavy_create), because a failed population could not be rolled back consistently on all replicas there.
materialized_views_squash_parallel_inserts
Squash inserts to materialized views destination table of a single INSERT query from parallel inserts to reduce amount of generated parts.
If set to false and parallel_view_processing is enabled, INSERT query will generate part in the destination table for each max_insert_thread. Last modified on August 11, 2026
