Sven Klemm

There is a memory leak in our function telemetry. As a temporary workaround you can disable function telemetry like so: ``` ALTER DATABASE SET timescaledb.telemetry_level to no_functions; ```

The issue reported by @bgemmill is different from the one initially reported here.

This seems to be a planner cost issue not a problem with the SkipScan code itself.

@Yamakaky could you provide reproduction steps ideally in the form of a self-contained sql script to reproduce the issue?

Fixed by #4641

Hello, this is missing migrations scripts for the changed fields in `sql/updates/latest-dev.sql` and downgrade scripts in `sql/updates/reverse-dev.sql`

Seems like this is only a problem when the job errors. Couldn't reproduce it in normal operation.

It seems like you are running into postgres limitations here. The 8160 byte row limit is the maximum size a row can have and short of recompiling postgres with a...

Can you try to upgrade to PG14 i could reproduce a similar behaviour on PG13 but the memory allocations seem to be inside postgres code.

I think you should not tie it to scalar expressions as this could potentially be useful in other situations too. Do you know if any our current tests hit that...