Hi Vishal,
In your example, “/var/lib/postgresql/data” should be the directory on your host [Windows] system. I don’t think you have this directory in Windows.
In my example, I have a drive F: and map a host directory on this drive “f:/data/docker/postgresql/data” to the postgres data directory /var/lib/postgresql/data. Setting the PGDATA environment variable resolves the fsync errors that I received.
Thank you for quick response. In the snippet I used from your quote, PGDATA points to “/tmp” which would mean PG will use /tmp as data directory inside container. I assume then PG doesn’t use “/var/lib/postgresql/data” directory as data directory.
In that case, I am not very sure if mapping “/var/lib/postgresql/data” container directory to x directory on host system would do any help. Doing this surely resolves all errors, but the “f:/data/docker/postgresql/data” directory on host system doesn’t really reflect the up-to-date data of PG, because it is now residing in /tmp.
As I am still learning docker, am I missing some point here?
When you’re using Docker for Windows to volume-mount a Windows drive into a Linux container, that volume is done using a CIFS/Samba network share from the Windows host. For lots of reasons, it’s highly unlikely that Linux Postgres will work correctly when trying to write data to a filesystem backed by NTFS shared with Samba.
After, creating the “data” volume, I did a docker-compose. Everything initialized fine (no errors). I then created a database and loaded it with data. I then did a docker-compose down followed by a docker-compose up and the data was still there.
The thing that I am unsure of is where on the disk is this data stored. docker volume inspect does not provide any meaningful information.
when I run docker-compose up I got following errors:
postgres_1 | FATAL: "/var/lib/postgresql/data" is not a valid data directory
postgres_1 | DETAIL: File "/var/lib/postgresql/data/PG_VERSION" does not contain valid data.
postgres_1 | HINT: You might need to initdb.
I confirm that this issue affect version 9.5 and 9.6. The only version that finally get this issue rectified is version 10.
So if you could not afford to use version 10, here is my fix:
FROM postgres:9.4
RUN mkdir -p "$PGDATA" && chmod 700 "$PGDATA"
The gist is to explicitly specifiy PGDATA and ask docker-compose to use my custom Dockerfile.postgres file to build the image. The RUN rule is very self-explanatory, I create a new folder and change mod to 700. And viola, it works
One solution to this problem was to create a user:
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: mypass
POSTGRES_DB: db
PGDATA: / tmp
Even so, it received errors in running both creation and migration. When I parse the docker log <db_id> I saw that the authentication problem continued. This way, again passing the “-A” option, both for db: create, and for the db: migrate option I was successful.
docker-compose run app bundle exec db: create -A
docker-compose run app bundle exec db: migrate -A
With this, I did not have to run chmod in version 3 of dockerfile.
EXPOSE 5432 CMD [“postgres”]
docker run -d -p 5435:5432 --name postgres postgres
it is creating container but not starting the container
please if anybody knows please reply
docker logs postgres
is also not showing any logs too
I have this problem on linux with laradock, after moving original data path host to another disk.
To solve that, add environment var PGDATA: /tmp , build, up and bash. Inside container, go to /var/lib/postgresql/ and create data2 folder. Copy all from data > data2 and run chown -R postgres:postgres data2/.
Exit and stop container. Remove PGDATA: /tmp and change docker-compose.yml like this:
Specifying the --user flag seems to map the folder with the correct uid and gid.
Check this out, it works here:
database:
image: 'postgres:13.2'
user: 999:999
volumes:
- ./volumes/database-data:/var/lib/postgresql/data/pgdata
environment:
PGDATA: /var/lib/postgresql/data/pgdata
# Permissions bug on macos: the volume is mounted as root the first instant, then it's mapped to 999. If we
# start with postgres directly it complains, if we start it after bash it's fine. It needs to wait at least 2
# seconds for some f* reason
entrypoint: bash -lc "sleep 2; /usr/lib/postgresql/13/bin/postgres"
As an addition to @activecod3’s post, I think it’s usefull to be aware what the DockerHub description of the image says regarding --user (when using docker run) or user: (when using docker compose)