Replies: 3 comments 1 reply
|
do you have any logs to share? |
|
Here are some logs from running |
|
Thanks — that's enough to pin it down. Your instinct is right: this is the Retain/consolidation keep working because they touch small incremental batches; graph_maintenance does a bank-wide sweep of the co-occurrence graph, and on the Can you confirm the exact exception? The journalctl -u hindsight.service -o cat | grep -A 40 "Task execution failed: graph_maintenance" | grep -i "timeout\|QueryCanceled\|canceling statement"I expect Two things to try, in order: 1. Refresh planner stats first — this is usually the real fix. A bank-wide DELETE that "suddenly" times out while incremental ops stay fast is almost always a stale-statistics bad plan (nested loop instead of a hash/merge). Run against your DB: VACUUM ANALYZE entity_cooccurrences;
VACUUM ANALYZE unit_entities;
VACUUM ANALYZE entities;Then let the next SELECT relname, n_live_tup, last_autovacuum, last_autoanalyze
FROM pg_stat_user_tables
WHERE relname IN ('entity_cooccurrences','unit_entities','entities');2. If it's genuinely just large, give the first sweep more room. Temporarily raise (or disable) the statement timeout so the backlog can drain once, then restart: After the first successful full prune, later runs only handle the small delta and finish well under the default, so you can set it back to Separately, I'll harden this on our side — the bank-wide co-occurrence prune should be batched so it can never exceed |
Uh oh!
There was an error while loading. Please reload this page.
Hi Everyone,
I checked my hindsight control panel after a while and noticed that all my graph maintenances are failing. Retain and consolidations are all working perfectly. Any ideas why this might be the case? I am on v0.8.3
All reactions