Fabrízio de Royes Mello

No PostgreSQL existe a libpg_query para efetuar o parser SQL corretamente: https://github.com/pganalyze/libpg_query

@turicas tem como complementar aqui com informações mais detalhadas das queries problemáticas e também seus planos de execução?

> I don't quite understand the reasoning behind this change. Are we saying that those indices are useless now due to the final form? In that case we could remove...

@michaelkitson thanks for reporting this... seems this is an oversight and we're not dealing properly with default privileges for continuous aggregates (propagating to the underlying materialization hypertable). The problem here...

@michaelkitson fixed in PR #4580

@GeorgeDevol thanks for reporting. Actually this is not a bug and is documented here: https://docs.timescale.com/timescaledb/latest/how-to-guides/continuous-aggregates/create-a-continuous-aggregate/#create-a-continuous-aggregate In the 2.7.0 version we released a new Continuous Aggregate that changed the internal format...

@svenklemm often I face this flaky test... seems is something related to the `test.remote_exec` but I didn't deep dive on it. Shouldn't be better place it to the IGNORE list?

Hey @boxhock ... did u had a change to get a stack trace as Nikhil asked before?

@hardikm10 currently we check the `time_bucket` interval during the execution of this function, it means that during the CAgg creation we didn't check it, just when try to execute it,...

Also you should check and change some regression tests, for example: ```bash ➜ git grep 'SELECT \* FROM timescaledb_information.job_stats' bgw_custom.sql:SELECT * FROM timescaledb_information.job_stats WHERE job_id > 1000; bgw_db_scheduler.sql:SELECT * FROM...