Sven Klemm

Do you still get this with the latest version? If so could you provide a minimal test script that reproduces the behaviour in a fresh database.

All of the queries you posted work for me on main-branch. Are you sure you tested latest version? ``` sven@i4774_2[3476275]=# SELECT commit_hash,commit_time FROM _timescaledb_internal.get_git_commit(); commit_hash | commit_time ------------------------------------------+------------------------ 1d4b9d6977098e74ad10888c2b44e8faf187458b |...

I still cannot reproduce: ``` app=# SELECT app-# time_bucket_gapfill('1 hour', a.timestamp) AS bucket, app-# COALESCE(COUNT(*), 0) AS ct app-# FROM app-# table_a AS a app-# LEFT JOIN app-# table_b AS...

How are you running the queries? table_a and table_b only have 1 row each is your data different?

I've adjusted the title, it's still a bug but severity is lower since it only occurs with cursors.

Doesnt fail for me: ``` sven@i4774[1238679]=# SELECT time_bucket_gapfill('1 day', a.timestamp) AS bucket, COALESCE(COUNT(*), 0) AS ct FROM table_a AS a LEFT JOIN table_b AS b ON b.id = a.id AND...

Hi @bijaymandal362, none of those log messages you are seeging are due to timescaledb internal functions now living in the `_timescaledb_functions` schema. While we did move all our functions and...

There is a bug preventing this from happening with unique expression indexes, for non-expression indexes it should work in 2.13. See https://github.com/timescale/timescaledb/pull/6454

I've triggered a rebuild, new images should be available in an hour.

Why did you think data was stored in /home/postgresql? Is this documented somewhere?