Skip to content

[Bug]: refresh window size is smaller than or equal to batch size #8850

@michalk-k

Description

@michalk-k

What type of bug is this?

Other

What subsystems and features are affected?

Continuous aggregate

What happened?

I recently upgraded from 2.18 to 2.22.1
No issues spotted with 2.18.
Since the new version, I have encountered repeating log records:

2025-10-27 19:36:55.076 UTC [11401] LOG:  refresh window size (00:05:00) is smaller than or equal to batch size (00:05:00), falling back to single batch processing

The good news is that data in CAGGs are being updated.
But I don't understand what caused it. I know that the refresh window has to be at least twice as large as the batch size (given by time_bucket()).

Since the add_continuous_aggregate_policy() prevents breaking this constraint, my refresh policy for this CAGG is

SELECT add_continuous_aggregate_policy(
   continuous_aggregate => 'ltss_ha_metrics.cagg_energy_5mins',
   start_offset         => '15 minutes'::INTERVAL,
   end_offset           => '5 minutes'::INTERVAL,
   schedule_interval    => '2.5 minutes'::INTERVAL
);

CAGG definition

SELECT _materialized_hypertable_24.bucket,
    _materialized_hypertable_24.entity_id,
    _materialized_hypertable_24.min_value,
    _materialized_hypertable_24.max_value,
    _materialized_hypertable_24.perc_agg
   FROM _timescaledb_internal._materialized_hypertable_24
  WHERE (_materialized_hypertable_24.bucket < COALESCE(_timescaledb_functions.to_timestamp(_timescaledb_functions.cagg_watermark(24)), '-infinity'::timestamp with time zone))
UNION ALL
 SELECT time_bucket('00:05:00'::interval, ltss."time", 'Europe/Prague'::text) AS bucket,
    ltss.entity_id,
    min((ltss.state)::text) AS min_value,
    max((ltss.state)::text) AS max_value,
    percentile_agg((ltss.state)::double precision) AS perc_agg
   FROM ltss
  WHERE ((((ltss.entity_id)::text = ANY (ltss_ha_metrics.get_entities_for_cagg_hametrics())) AND ((ltss.state)::text <> ALL ((ARRAY['unavailable'::character varying, 'unknown'::character varying])::text[]))) AND (ltss."time" >= COALESCE(_timescaledb_functions.to_timestamp(_timescaledb_functions.cagg_watermark(24)), '-infinity'::timestamp with time zone)))
  GROUP BY (time_bucket('00:05:00'::interval, ltss."time", 'Europe/Prague'::text)), ltss.entity_id;

By trial and error, I found that the notification is no longer reported if I set start_offset to 20 minutes.
I tried with 15, 16, 17 minutes... all raised this notification.

Is it an issue? If not, I would like to learn which feature/requirement this behavior is related to, and why it did not appear in 2.18.

TimescaleDB version affected

2.22.1

PostgreSQL version used

17.6

What operating system did you use?

HomeAssistant OS, on aarch64-alpine-linux-musl, compiled by gcc (Alpine 14.2.0) 14.2.0, 64-bit

What installation method did you use?

Docker

What platform did you run on?

On prem/Self-hosted

Relevant log output and stack trace

How can we reproduce the bug?

See description

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions