You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In timescale#8117 we allowed concurrent CAgg refreshes by relaxing the strong
lock when processing the invalidation by locking those rows and skipping
the lock when the lock was already taken. The problem was when we had
only one invalidation log to either expand or contract that the first
session take the lock and the second skip the lock and return to the
user that the CAgg is up-to-date and this is wrong.
So in order to improve and fix this wrong behavior we've splitted the
second transaction (data materialization) into two transactions:
1. process the cagg invalidation logs (expand/contract) and insert the
ranges to be materialized into a new metadata table named
`_timescaledb_catalog.continuous_aggs_materialization_ranges` to
process the materialization in the next transaction
2. process the materialization by reading ranges using FOR UPDATE SKIP
LOCK from the new metadata table, execute the materialization and at
the end remove the row from the new metadata table.
This new approach is like a producer/consumer pattern where the first
transaction produce items in the queue to be consumed and processed by
the next transaction.
0 commit comments