Add possibility to customize the postgres server even if a database already exists

[elofu17]

I'm running a postgres (debian) container.
A database has been created.

Later I see performance issues due to the JIT compiler (it takes way more time to plan/evaluate than just executing the quick query).
So I want to add jit = off to my postgresql.conf

I created the file /docker-entrypoint-initdb.d/10-postgresql.conf_disable_jit.sh inside the container :

#!/bin/bash
/bin/grep -q '^jit = off$' /var/lib/postgresql/data/pgdata/postgresql.conf || /bin/echo -e '\n# Added by 10-postgresql.conf_disable_jit.sh:\njit = off' >> /var/lib/postgresql/data/pgdata/postgresql.conf

Unfortunately, this script is not executed.. :-/
If a database already exists, all custom initialization scripts are skipped!

Request:
Add a second custom container initialization directory, and always execute the scripts therein.
Like:
/docker-custom-entrypoint.d/

This way we can customize the container, the postgres server itself, etc via this directory, and customize databases using the /docker-entrypoint-initdb.d/ dir.

Then I would have been able to place my script in /docker-custom-entrypoint.d/10-postgresql.conf_disable_jit.sh instead.

[tianon]

Conceptually, this is very similar to #173, #821, #191 (to link a few). I think #821 (comment) is really relevant:

this would be extremely disruptive for us to implement generally (since we'd have to start and stop and start again the server on every container startup, which is not generally acceptable)

For things like this where you just want to run a script before starting the process, I'd suggest you just add a new entrypoint script which does what you're looking for, then chain-loads to the real one via exec docker-entrypoint.sh postgres.

[elofu17]

Ah! Yes, that's an alternative approach. Thanks! :-)

Since there are quite a few requests for this feature, more people than me didn't think of your suggestion.
To lower the amount of new (unneccessary) tickets like this, I suggest that you add two examples in the README.md to show people like me how to do this customization.

Like, after the sentence "Warning: scripts in /docker-entrypoint-initdb.d are only run if you start the container with a data directory that is empty" you can add: "(see section below for advanced customization)" and then add a section that show two examples on how to override the original entrypoint on the commandline (docker run) and via docker compose.

Here's an example you can copy as a base:

Custom override of entrypoint using docker compose:
Create a script with your custom changes and then continue loading the original entrypoint:

/path/to/my/postgres-custom-entrypoint-override.sh :

#!/bin/bash
# If not already done, disable JIT
/bin/grep -q '^jit = off$' /var/lib/postgresql/data/pgdata/postgresql.conf || /bin/echo -e '\n# Added by /custom-entrypoint-override.sh:\n# JIT (just in time compilation) in postgres takes much more time to plan & evaluate than the actual query, so we disable it.\n# Otherwise PuppetExplorer queries towards the facts endpoint will take 40 seconds.\njit = off' >> /var/lib/postgresql/data/pgdata/postgresql.conf
# Now chain-load the container's original entrypoint:
exec /docker-entrypoint.sh postgres

Make it executable: chmod 755 /path/to/my/postgres-custom-entrypoint-override.sh

Bind-mount the file into the container and override the entrypoint:

# edit docker-compose.yml
version: '3.7'
services:
  postgres:
    volumes:
      - /path/to/my/postgres-custom-entrypoint-override.sh:/custom-entrypoint-override.sh
    entrypoint: /custom-entrypoint-override.sh

Run docker-compose up to start your customized container.

Custom override of entrypoint using docker run:
Foo bar fum.

[tianon]

Unfortunately, this is currently implemented as much as we plan to do so (with modular docker-entrypoint.sh). 👍

[voroninp]

@tianon , hi, could you explain why it is so?

this would be extremely disruptive for us to implement generally (since we'd have to start and stop and start again the server on every container startup, which is not generally acceptable)

[tianon]

We can't run SQL commands against PostgreSQL (generally) unless it is running and we have an appropriate method of access, and we can't start up PostgreSQL as the container's "PID 1" and still run more code reliably (nor can we start it and then "graduate" that instance to be PID 1), so it would have to be the same as it is during our existing initdb logic: start in local-listening-only mode, connect and do the thing, then shut down, then start up the "real" server.

[voroninp]

Thanks, now it's clear. So to make it possible, server itself should support this.