[Bug]: Postgresql container hangs when using .withFileSystemBind

[zapp88]

Module

PostgreSQL

Testcontainers version

1.20.6

Using the latest Testcontainers version?

Yes

Host OS

Linux,Windows,Mac

Host Arch

x86,arm

Docker version

Client:
 Version:           28.0.4
 API version:       1.48
 Go version:        go1.23.7
 Git commit:        b8034c0
 Built:             Tue Mar 25 15:07:48 2025
 OS/Arch:           windows/amd64
 Context:           desktop-linux

Server: Docker Desktop 4.40.0 (187762)
 Engine:
  Version:          28.0.4
  API version:      1.48 (minimum version 1.24)
  Go version:       go1.23.7
  Git commit:       6430e49
  Built:            Tue Mar 25 15:07:22 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.26
  GitCommit:        753481ec61c7c8955a23d6ff7bc8e4daed455734
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

What happened?

Let’s assume the following scenario: instead of starting the container once and forgetting about it, we want to persist data across container restarts by using:

.withFileSystemBind("./postgresql", "/var/lib/postgresql/data", BindMode.READ_WRITE);

When the container is started for the first time, everything works as expected. However, when it is started a second time, it hangs indefinitely.

The culprit is this line 46 in PostgreSQLContainer.class:

this.waitStrategy = (new LogMessageWaitStrategy())
    .withRegEx(".*database system is ready to accept connections.*\\s")
    .withTimes(2)
    .withStartupTimeout(Duration.of(60L, ChronoUnit.SECONDS));

Specifically: .withTimes(2)

When the container is started with existing data, the log message "database system is ready to accept connections" appears only once.

The fix is to change .withTimes(2) to .withTimes(1). This change doesn’t break any existing functionality—the container still starts successfully, and we are able to connect to it as soon as the message appears. Additionally, it ensures proper startup even when the container is restarted with pre-existing data.

Relevant log output

Additional Information

No response

[zapp88]

Or, if the proposed bug fix is not acceptable, a more robust approach would be to change the waitStrategy to:

new ShellStrategy().withCommand("pg_isready -U postgres");