Feature/image size optimisation

[Miggets7]

Reduces some of the size.
#12

[richturner]

This is a great step in the right direction I think we should limit our images to only include the version of postgres used in our last major release so the idea is you can do rolling upgrades with the various tag versions if needed, we can cut more out of this image then.

Init script should check if old version is one supported.

[richturner]

• If using a bash script then this should be reused by the github workflow to avoid duplication.
• Is there any value in removing some of the TS versions from the build?
• Don't know how slim works but hopefully there isn't something it has missed in its' optimisation also does it provide enough benefit to warrant the extra dependency vs. just manually deleting stuff out of the image
• If sticking with a bash script then use --build-arg to pass PG_MAJOR to docker build otherwise there is a potential mismatch issue.

[Miggets7]

@richturner

Is there any value in removing some of the TS versions from the build?

Not sure, but no TS version gets removed? The Dockerfile uses timescale/timescaledb-ha base image which includes multiple TimescaleDB versions.

Don't know how slim works but hopefully there isn't something it has missed in its' optimisation also does it provide enough benefit to warrant the extra dependency vs. just manually deleting stuff out of the image

Slim is a tool that runs the container, monitors which files are actually accessed, and removes everything else. We whitelist specific paths (PostgreSQL dirs, shell utilities used by the entrypoint) to ensure nothing critical is removed.

Why slim vs alternatives:

• Manual rm -rf in Dockerfile - Would require deep knowledge of all PostgreSQL/TimescaleDB runtime dependencies and ongoing maintenance as versions change. Doable but time-consuming and error-prone.

• Scratch/distroless base - Would need to manually trace and copy every binary + all its shared library dependencies (ldd output). PostgreSQL has complex deps (locales, timezone data, SSL certs, etc.) plus our entrypoint uses many shell utilities. This would take a lot of time to get right and would be fragile.

Slim provides ~60% size reduction with minimal effort. The trade-off is an extra CI dependency (installed via one-liner script) and the risk of missing edge-case files - which we mitigate with explicit --include-path and --include-bin flags for known requirements.

[richturner]

Just built image locally without slim and started the container with a 14.6.0.3 DB and the container doesn't start but I also don't get the expected error messages in docker logs, just see this:

/usr/bin/env: ‘bash\r’: No such file or directory

[richturner]

Just built image locally without slim and started the container with a 14.6.0.3 DB and the container doesn't start but I also don't get the expected error messages in docker logs, just see this:

/usr/bin/env: ‘bash\r’: No such file or directory

Ignore I think this is a lie ending issue with gihub checkout

[richturner]

I upgraded from 14.6.0.3 -> 15.6.0.4 the tried using this image and it fails:

------------------------------------
New database initialisation complete
------------------------------------
---------------------------------------
Running pg_upgrade command, from /var/lib/postgresql/data
---------------------------------------
Running pg_upgrade --check first...
Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok
Checking database user is the install user                    ok
Checking database connection settings                         ok
Checking for prepared transactions                            ok
Checking for contrib/isn with bigint-passing mismatch         ok
Checking data type usage                                      ok
Checking for not-null constraint inconsistencies              ok
Checking for presence of required libraries                   fatal

Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
    /var/lib/postgresql/data/new/pg_upgrade_output.d/20260115T122704.976/loadable_libraries.txt
Failure, exiting
Running actual pg_upgrade with --link...
Performing Consistency Checks
-----------------------------
Checking cluster versions                                     ok
Checking database user is the install user                    ok
Checking database connection settings                         ok
Checking for prepared transactions                            ok
Checking for contrib/isn with bigint-passing mismatch         ok
Checking data type usage                                      ok
Checking for not-null constraint inconsistencies              ok
Creating dump of global objects                               ok
Creating dump of database schemas                             ok
Checking for presence of required libraries                   fatal

Your installation references loadable libraries that are missing from the
new installation.  You can add these libraries to the new installation,
or remove the functions using them from the old installation.  A list of
problem libraries is in the file:
    /var/lib/postgresql/data/new/pg_upgrade_output.d/20260115T122705.758/loadable_libraries.txt
Failure, exiting

[richturner]

Here's the loadable_libraries.txt output:

could not load library "$libdir/timescaledb-2.9.1": ERROR:  could not access file "$libdir/timescaledb-2.9.1": No such file or directory
In database: template1
In database: postgres
In database: openremote
could not load library "$libdir/timescaledb_toolkit-1.13.1": ERROR:  could not access file "$libdir/timescaledb_toolkit-1.13.1": No such file or directory
In database: template1
In database: postgres
In database: openremote

[richturner]

I can see 2.9.1 in /usr/lib/postgresql/15/lib but not in /usr/lib/postgresql/17/lib don't know why the timescale upgrade didn't resolve this