Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Check if database is present on every run, not just on init #173

Closed
rudyryk opened this issue Jul 9, 2016 · 4 comments
Closed

Check if database is present on every run, not just on init #173

rudyryk opened this issue Jul 9, 2016 · 4 comments
Labels
Request Request for image modification or feature

Comments

@rudyryk
Copy link

rudyryk commented Jul 9, 2016

As far as I can see from the docker-entrypoint.sh it checks for the presence of database only on the first container start.

I suggest performing this check on every start.

I see some possible scenarios:

  1. Database was dropped for cleanup, we'd expect it to be just re-created
  2. Database name was changed via ${POSTGRES_DB}, so we'd expect the new database to be created

So In both cases, we just should check if the database already exists and if not then create a new one.

I'm not good at shell programming, not sure if I can make a PR :)

@yosifkit
Copy link
Member

That might be possible for the POSTGRES_DB variable but then some users might expect the same behavior when they change user or password variables. I don't think it would be reasonable to delete or disable any other users or recreate the user/password they specified.

@rudyryk
Copy link
Author

rudyryk commented Jul 13, 2016

@yosifkit I agree :) A also thought of that issue.

As I can see there are 3 common strategies for such cases:

  1. Don't perform any checks on 2-nd startup (after init is performed) - current implementation
  2. Fail fast - try to connect with the provided config and exit with error on fail
  3. Try to repair - if can't connect to the provided database, then create a new one (and probably create a new user also)

Probably the cleanest and the most explicit is the "Fail fast" option. With some examples in docs how to repair manually, e. g. run CREATE DATABASE query etc.

The downside of "Try to repair" option is the risk of "zombie" databases which is never actually used. But it's also more convenient as it provides max automation.

The first option seems a little bit confusing to me: a "broken" container may run without reporting any errors. Maybe some warnings would be helpful.

@bizmate
Copy link

bizmate commented Jul 26, 2017

I have a similar use case I would like to be able to leverage on this image/container. I am writing it here but I can definitely open a separate issue if better.

Just like @rudyryk requirement the core question is if at re-init (so if a container is created again) the creation of the db or any other init operation (just like the running of the scripts in /docker-entrypoint-initdb.d) should be done again or at least checked.

I am using a init.sh inside /docker-entrypoint-initdb.d and it is not rerun when I down and up my container (reference to docker-compose). I have the data mounted from a volume and so the db is always there but also perform some checks on the init script that might rerun some small changes on the new container.

Would it be reasonable to have an extra piece of functionality that allowed to force the init on every container creation?

ie POSTGRES_INIT_FORCE = true as an env variable

@tianon
Copy link
Member

tianon commented Jun 8, 2022

Whew, coming back to this one after eons 😅

Unfortunately, this is not behavior that we're going to implement in the image as-is. However, the customization provided by #496 makes it somewhat more straightforward than it was before to replicate/create this behavior yourself -- high-level, you'd source docker-entrypoint.sh and invoke the functions from _main in the same order, but changing the initialization condition to only wrap up the initial initialization instead of the entire temporary server code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Request Request for image modification or feature
Projects
None yet
Development

No branches or pull requests

5 participants