in volumes section you specify path to dirs not path to files

change

volumes:
   ./postgresql/init.sql:/docker-entrypoint-initdb.d/init.sql

to

volumes:
   ./postgresql:/docker-entrypoint-initdb.d

or to

volumes:
   <path to dir with init.sql>:/docker-entrypoint-initdb.d

where <path to dir with init.sql> is propper local path

I could reproduce your issue by creating and actual folder:

mkdir ./scripts/postgres/0-schema.sql
docker-compose up

Then I get exactly your error:

postgres       | /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/0-schema.sql
postgres       | psql:/docker-entrypoint-initdb.d/0-schema.sql:0: could not read from input file: Is a directory

Double check your local setup because you might have a folder called 1-schema.sql in your "scripts/postgres" folder. Check this by running in your project folder:

ls -lart ./scripts/postgres

1. Maybe this has already been answered above, but "init.sql" is a very misleading name IF it is used for the directory; because it appears to be just a single SQL initialization script/file. So instead of:

   ...
   volumes:
     - ./init.sql:/docker-entrypoint-initdb.d/init.sql
   ...
   

   ... I would suggest something like the following (from a MySQL DB in Docker Compose env that is IMHO completely analogous):

   ...
   volumes:
     - ./database/:/docker-entrypoint-initdb.d
   ...
   

2. AFAIK depends_on does NOT use healthcheck ANYMORE (since Docker Compose v3)

   • https://stackoverflow.com/a/59072727/8509622
   • https://docs.docker.com/compose/compose-file/compose-file-v3/#depends_on

   And the strongly recommended approach: https://docs.docker.com/compose/startup-order/

   The problem of waiting for a database (for example) to be ready is really just a subset of a much larger problem of distributed systems. In production, your database could become unavailable or move hosts at any time. Your application needs to be resilient to these types of failures. To handle this, design your application to attempt to re-establish a connection to the database after a failure. If the application retries the connection, it can eventually connect to the database. The best solution is to perform this check in your application code, both at startup and whenever a connection is lost for any reason.

   However, if you don’t need this level of resilience, you can work around the problem with a wrapper script: [...]

Had the same problem with postgres 11.

Some points that helped me:

• run:
  • docker-compose rm
  • docker-compose build
  • docker-compose up
• The obvious: don't run compose in detached mode. You want to see the logs.

After adding the step docker-compose rm to the mix it worked, finally.

Initialize Postgres container with Data

Create a docker-compose.yml

services:
  postgress-postgresql:
    image: postgres:bullseye
    container_name: postgres
    volumes:
      - postgresql_data:/var/lib/postgresql/data/
      - ./init.sql:/docker-entrypoint-initdb.d/init.sql
    environment:
      - POSTGRES_USER=postgress
      - POSTGRES_PASSWORD=MyStrongPassword123
    ports:
      - 5432:5432
    networks:
      - postgres
networks:
  postgres:
volumes:
  postgresql_data:

Create a init.sql with the script

 CREATE USER vbv WITH PASSWORD 'vbv';
 CREATE DATABASE vbvdb;
 GRANT ALL PRIVILEGES ON DATABASE vbvdb TO vbv;
 
 \connect vbvdb;
 
 CREATE TABLE employees (
     id SERIAL PRIMARY KEY,
     name VARCHAR(100),
     position VARCHAR(50),
     salary DECIMAL(10, 2)
 );
 
 INSERT INTO employees (name, position, salary) VALUES
 ('Bhuvi', 'Manager', 675000.00),
 ('Vibhu', 'Developer', 555000.00),
 ('Rudra', 'Analyst', 460000.00);
 
 GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA public TO vbv;

RUN with docker-compose up -d

Connect to the container psql client - docker exec -it postgres bash. Check the data exists.

 ➜  ~ docker exec -it postgres bash
 root@96a599122941:/# psql -U vbv -d vbvdb
 psql (17.0 (Debian 17.0-1.pgdg110+1))
 Type "help" for help.
 
 vbvdb=> SELECT * FROM employees;
  id | name  | position  |  salary  
 ----+-------+-----------+----------
   1 | Bhuvi | Manager   | 675000.00
   2 | Vibhu | Developer | 555000.00
   3 | Rudra | Analyst   | 460000.00
 (3 rows)
 
 vbvdb=>

You can also validate docker logs -f postgres contains the following.

 2024-10-04 08:04:03.810 UTC [48] LOG:  database system is ready to accept connections
  done
 server started
 CREATE DATABASE
 
 
 /usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init.sql
 CREATE ROLE
 CREATE DATABASE
 GRANT
 You are now connected to database "vbvdb" as user "postgress".
 CREATE TABLE
 INSERT 0 3
 GRANT

Added the activity logs into the gist https://gist.github.com/jinnabaalu/89bd8eeba3b8845cf337b85a807748f1

For me problem was in my machine. enabled SELinux access control, which did not allow for containers to expand files.

Solution, disable SELinux:

echo SELINUX=disabled > /etc/selinux/config
SELINUXTYPE=targeted >> /etc/selinux/config
setenforce 0

From this

You really have two questions here. First you have a corrupted tar file. I'd blame that on your usage of docker. If you run tar -tf ... on the docker side before moving the file, was it corrupted there?

Second, you don't want to restore data, you want to merge it. pg_dump/pg_restore doesn't do that. You will have to figure out what you want to do (overwrite, aggregate, assign new PKs and just insert them as new rows) and then implement that. You likely want to use COPY or \copy to get the data out of the first system so the second one can see it. After that, it is really up to you what you do with it. You can implement the merging in python or Perl or SQL (after \copy into staging tables) or whatever your favorite tool is.

I suspect that your error is caused by the behavior of the \i command:

\i or \include filename

Reads input from the file filename and executes it as though it had been typed on the keyboard.

As you can see from library/postgres:9.6 docker-entrypoint.sh file, .sql files are executed using psql -f (as scripts). Every included file is expected to be in psql's current working directory.

You should use \ir:

\ir or \include_relative filename

The \ir command is similar to \i, but resolves relative file names differently. When executing in interactive mode, the two commands behave identically. However, when invoked from a script, \ir interprets file names relative to the directory in which the script is located, rather than the current working directory.

Source: Postgres doc.

If you need to make this working with older versions of Postgres, check this answer.

Postgres only initializes the database if no database is found, when the container starts. Since you have a volume mapping on the database directory, chances are that a database already exists.

If you delete the db_data volume and start the container, postgres will see that there isn't a database and then it'll initialize one for you using the scripts in docker-entrypoint-initdb.d.

Solution

You should clear data_volume BEFORE running the container and the SQL files will be executed.

This volume data_volume can be removed by using command:

docker volume rm data_volume

The root cause of your problem can be found in docker-entrypoint.sh. When you run a MySQL container, it checks if MySQL directory /var/lib/mysql exist or not. If the directory doesn't exist (running it the first time), it will run your SQL files.

if [ ! -d "$DATADIR/mysql" ]; then
    // Some other logic here

    for f in /docker-entrypoint-initdb.d/*; do
        case "$f" in
            *.sh)     echo "$0: running $f"; . "$f" ;;
            *.sql)    echo "$0: running $f"; "${mysql[@]}" < "$f"; echo ;;
            *.sql.gz) echo "$0: running $f"; gunzip -c "$f" | "${mysql[@]}"; echo ;;
            *)        echo "$0: ignoring $f" ;;
        esac
        echo
    done 

You can get more details from MySQL docker-entrypoint.sh source file.