Observed repeatedly on a production field instance (276+ GB query_stats), including immediately before collection resumed after tonight's upgrade:
Failed to seed delta calculator from Postgres store... Exception while reading from stream
Same signature class as #1757 (Npgsql client-side timeout; silent server log), but a DIFFERENT consumer: #1762 rewired the eleven BASELINE families onto the collection-grain tier, and the delta-calculator seed path was not part of that scope. This is a separate unfixed read site, not corroboration of the fixed one - filing it so it has its own number now that #1757 is closed.
Investigation first, not assumption: find the seed query (collector runner startup path - it seeds per-server delta state from recent store rows), and determine why it is expensive on a large store. Likely suspects in order: (a) missing/ineffective time bound so TimescaleDB cannot chunk-exclude (the same wall the D2b verification query hit in the field - even a bare filtered count(*) times out on that store without a collection_time bound); (b) a per-query-hash scan shape that degenerates with table size; (c) simply the default 30s CommandTimeout on a legitimately-heavy one-time read.
Fix by the house rule: prefer the proven fast idiom (tight time-bounded read that chunk-excludes, or a purpose-built source) over a timeout bump; a bounded one-time startup read with its OWN generous timeout is acceptable only if the read is genuinely irreducible. Note the restart-reseed history (#1577/#1578) - this path has bitten before in a different way; whoever fixes it should read that context so the fix does not regress the reseed-starvation work.
Observed repeatedly on a production field instance (276+ GB query_stats), including immediately before collection resumed after tonight's upgrade:
Same signature class as #1757 (Npgsql client-side timeout; silent server log), but a DIFFERENT consumer: #1762 rewired the eleven BASELINE families onto the collection-grain tier, and the delta-calculator seed path was not part of that scope. This is a separate unfixed read site, not corroboration of the fixed one - filing it so it has its own number now that #1757 is closed.
Investigation first, not assumption: find the seed query (collector runner startup path - it seeds per-server delta state from recent store rows), and determine why it is expensive on a large store. Likely suspects in order: (a) missing/ineffective time bound so TimescaleDB cannot chunk-exclude (the same wall the D2b verification query hit in the field - even a bare filtered count(*) times out on that store without a collection_time bound); (b) a per-query-hash scan shape that degenerates with table size; (c) simply the default 30s CommandTimeout on a legitimately-heavy one-time read.
Fix by the house rule: prefer the proven fast idiom (tight time-bounded read that chunk-excludes, or a purpose-built source) over a timeout bump; a bounded one-time startup read with its OWN generous timeout is acceptable only if the read is genuinely irreducible. Note the restart-reseed history (#1577/#1578) - this path has bitten before in a different way; whoever fixes it should read that context so the fix does not regress the reseed-starvation work.