Closed iarenaza closed 3 months ago
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.
@iarenaza could you please sign the contributor license agreement.
Hello, this change seems to break the TS_TUNE base script if run locally. I.e. we see errors like this:
timescale> /docker-entrypoint.sh: sourcing /docker-entrypoint-initdb.d/000_install_timescaledb.sh
timescale> CREATE EXTENSION
timescale> 2024-07-02 00:22:27.628 UTC [57] ERROR: TimescaleDB background worker connected to template database, exiting
timescale> CREATE EXTENSION
timescale>
timescale> /docker-entrypoint.sh: running /docker-entrypoint-initdb.d/001_timescaledb_tune.sh
timescale> 2024-07-02 00:22:27.630 UTC [35] LOG: background worker "TimescaleDB Background Worker Scheduler" (PID 57) exited with exit code 1
timescale> /docker-entrypoint-initdb.d/001_timescaledb_tune.sh: line 42: [: max: integer expression expected
This was run on an M3 mac. Any ideas why this may be happening?
The old implementation only checked the sysfs files corresponding to cgroups v1. Most Linux distribution kernels have switched to cgroups v2 several years ago, which uses a different set of paths for various settings (memory limits included).
The net effect of the old implementation was that it completely ignored the memory limits, if the container was run in a kernel with cgroups v2 (in those kernels cgroups v1 are disabled by default).