ci: fix broken pg_isready readiness probe on the WarehousePG CI lane

.github/workflows/ci.yml

@@ -198,21 +198,46 @@ jobs:
             -e POSTGRES_DB=mcpg_test mcpg-ci-db
           if [ "${{ matrix.postgres }}" = "warehousepg-latest" ]; then
             DB_USER=gpadmin
-            # A single-node Greenplum-family coordinator+segment cluster
-            # takes much longer to initialize than a plain postgres
-            # container, so this lane gets a longer, coarser poll.
+          else
+            DB_USER=postgres
+          fi
+          echo "DB_USER=$DB_USER" >> "$GITHUB_ENV"
+          if [ "${{ matrix.postgres }}" = "warehousepg-latest" ]; then
+            # `woblerr/warehousepg` doesn't ship `pg_isready` on PATH — not
+            # documented upstream, confirmed by direct observation: every
+            # poll attempt with the pg_isready-based probe below fails with
+            # "executable file not found in $PATH", so it can never detect
+            # readiness and always burns its full poll budget (previously
+            # 90 * 4s = 360s) as dead time regardless of how fast the
+            # database actually comes up. Probe with `psql` instead — the
+            # runner's default client works here (see the "Install
+            # PostgreSQL client tools" step above, which skips a custom
+            # client for this lane on purpose) — connecting straight
+            # through the published port, the same path pytest itself
+            # uses. This also doubles as a stronger check than
+            # `pg_isready`: it only succeeds once the target database
+            # actually accepts queries, not just once the postmaster
+            # process is up. Keep the longer, coarser poll ceiling as a
+            # safety net — a single-node Greenplum-family
+            # coordinator+segment cluster can still legitimately take
+            # longer to initialize than a plain postgres container — but
+            # now the loop breaks as soon as it's actually ready instead
+            # of always waiting out the full ceiling.
             max_attempts=90
             sleep_secs=4
+            for _ in $(seq 1 "$max_attempts"); do
+              PGPASSWORD=postgres psql -h localhost -U "$DB_USER" -d mcpg_test -c 'SELECT 1' -q \
+                >/dev/null 2>&1 && break
+              sleep "$sleep_secs"
+            done
           else
-            DB_USER=postgres
             max_attempts=30
             sleep_secs=2
+            for _ in $(seq 1 "$max_attempts"); do
+              docker exec mcpg-db pg_isready -U "$DB_USER" && break
+              sleep "$sleep_secs"
+            done
           fi
-          echo "DB_USER=$DB_USER" >> "$GITHUB_ENV"
-          for _ in $(seq 1 "$max_attempts"); do
-            docker exec mcpg-db pg_isready -U "$DB_USER" && break
-            sleep "$sleep_secs"
-          done
       - name: Set up uv
         uses: astral-sh/setup-uv@20cfd1bf945f4377ade1205e4dbc17946fc9a30d # v10.0.1
         with:

CHANGELOG.md

@@ -6,6 +6,29 @@ adheres to [Semantic Versioning](https://semver.org/).
 
 ## [Unreleased]
 
+### Fixed
+
+- **Broken readiness probe on the `warehousepg-latest` CI lane was
+  burning ~6 minutes of dead time on every run.** The lane's readiness
+  poll used `docker exec mcpg-db pg_isready -U gpadmin`, but
+  `woblerr/warehousepg:7.4.1-WHPG` doesn't ship `pg_isready` on PATH —
+  every poll attempt failed with `exec: "pg_isready": executable file
+  not found in $PATH`, so the loop could never observe success and
+  always waited out its full 90 × 4s = 360s budget regardless of how
+  fast the database actually came up. Swapped the probe to `psql`
+  against the published port, the same path pytest itself uses —
+  identified from real `gh run view` timings (the "Start PostgreSQL"
+  step accounted for ~6-6.5 min of the lane's ~9-10 min total vs.
+  ~20-30s on every other PG version; the `pytest` step itself was
+  already the same duration as any other lane).
+
+### Security
+
+- **Bumped transitive `pip` 26.1.2 → 26.2.1 (PYSEC-2026-3721).**
+  `pip-audit`'s own `pip_api` dependency pulled in a `pip` version with
+  a known vulnerability, flagged by the local pre-commit hook's
+  dependency audit.
+
 ## [0.8.0] - 2026-08-19
 
 ### Security