[Bug]: PostgreSQLContainer skips the JDBC readiness gate, leaving host-side port reachability unverified

从已弃用的和新的 PostgreSQLContainer 实现开始，将它们的 waitUntilContainerStarted() 方法与 JdbcDatabaseContainer#waitUntilContainerStarted() 进行比较。验证在 JDBC 就绪检查之前，等待策略仍得到遵循，然后为主机侧连接就绪和自定义等待行为添加或更新测试。完成标准是 PostgreSQLContainer 覆盖这两个门槛，同时不使用户提供的等待策略发生回归。

Module

PostgreSQL

Problem

PostgreSQLContainer — both the deprecated org.testcontainers.containers.PostgreSQLContainer and the new org.testcontainers.postgresql.PostgreSQLContainer — overrides waitUntilContainerStarted() to call only the wait strategy:

@Override
protected void waitUntilContainerStarted() {
    getWaitStrategy().waitUntilReady(this);
}

This deliberately skips JdbcDatabaseContainer#waitUntilContainerStarted(), which repeatedly opens a JDBC connection from the host and runs the test query until it succeeds.

The consequence is that Postgres readiness is gated purely on container-side log output. Nothing verifies that the mapped port is routable from the calling JVM, or that a connection can actually be established. Every other JDBC container gets that host-side gate; Postgres is the exception.

On Docker environments that publish ports through a VM (Colima, Docker Desktop), the mapped host port can become routable slightly after database system is ready to accept connections appears in the log, so the first connection after start() returns Connection refused.

Why the override may no longer be needed

git log -L traces the override to #327, which fixed #317. The motive there was noise, not correctness: the Postgres JDBC driver had just moved to java.util.logging and was printing a stack trace for every failed attempt of the connect-retry loop. The PR description even says:

I've changed the PostgreSQLContainer to use the WaitingConsumer for waiting for Log output, instead of performing SQL queries. It's basically the same code as in LogWaitStrategy, but I've figured we'll refactor the JdbcDatabaseContainers at a later stage, to make use of a WaitStrategy?

That concern is handled independently today. PostgreSQLContainer#configure() sets:

// Disable Postgres driver use of java.util.logging to reduce noise at startup time
withUrlParam("loggerLevel", "OFF");

So the retry loop no longer produces the log spam the override was introduced to avoid.

Proposal

Have the override run the wait strategy and then delegate:

@Override
protected void waitUntilContainerStarted() {
    getWaitStrategy().waitUntilReady(this);
    super.waitUntilContainerStarted();
}

This keeps the property the override was preserving — a user-supplied waitingFor(...) is actually honored, which JdbcDatabaseContainer otherwise ignores entirely — while restoring the JDBC readiness gate that every other JDBC container already has.

Downstream context

Surfaced from testcontainers-jooq-codegen-maven-plugin#59. That plugin worked around the missing host-side gate by replacing the container's wait strategy with HostPortWaitStrategy, which then removed the log gate and let code generation run against a database still reporting FATAL: the database system is starting up. Neither gate alone is sufficient, and a downstream caller cannot compose them: GenericContainer#getWaitStrategy is protected, so external code cannot read a container's default in order to wrap it in a WaitAllStrategy.

Happy to open a PR if this direction looks right.