Environment information

• Mquery version (from the /status page): N/A (couldn't start)
• Ursadb version (from the /status page): N/A (couldn't start)
• Commit hash:
• Installation method:
  • Generic docker compose
  • Dev docker compose
  • Native (from source)
  • Other (please explain)

Reproduction Steps

• Clone the project repository.
• Configure .env appropriately
• Create the volume folders on the host and set compatible permissions
• Launch docker compose up --scale daemon=3

Actual behaviour the bug

The compose up command will fail with the following error:

Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error mounting "/srv/mquery-data/postgres" to rootfs at "/var/lib/postgresql/data": change mount propagation through procfd: open o_path procfd: open /var/lib/docker
/overlay2/109b128c0fb597861267ce07bfb5770f09d34bb6636b0c341af375ac5e1aff40/merged/var/lib/postgresql/data: no such file or directory: unknown

Origin of the bug

As found in this post it seems that Postgres 18 docker image moved the data path.
The difference can also be found in the docker files of Alpine Postgres for version 17 and for version 18.
Same breaking change is outlined here in the official docs as well where they state that for docker 18 the new data path volume whould be set to /var/lib/postgresql.

The mQuery's docker-compose.yml is implicitely latest which, now, automatically pulls version 18, causing the bug.

Proposed solution

I'm pushing a PR to fix this, in the PR I've added two explicit env variables.
For the default values I decided to stick to postgres 17, since it was the "latest" until a few days ago.
I haven't tested mquery with postgres 18 to be confident to push 18 as a default.

It's a quick patch, let me know if you have any comments or if you prefer to opt for a different solution.