Repository navigation
Wait for the final PostgreSQL fixture server - #248
Conversation
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars.
|
kjgbot
left a comment
There was a problem hiding this comment.
Source review of exact head 64fc8b2: no actionable findings. The official PostgreSQL entrypoint starts its temporary initialization server with listen_addresses empty, so explicitly probing 127.0.0.1 waits for final TCP startup. Independently reproduced the readiness/first-SQL boundary with a stateful fake Docker: old prefix exits 2; fixed prefix exits 0; permanent unready fixture still exits 1 at the existing bounded limit. Confirmed the entire script after the readiness wait (all role/SQL assertions) is byte-identical to base. bash -n and git diff --check pass. No real Docker, database or ar-lap operations performed; real PostgreSQL integration remains the CI fixture check.
[Low impact] This focused readiness fix appears safe to merge.
|
The RDS eraser-role fixture can pass
pg_isreadyagainst the PostgreSQL image's temporary Unix-socket initialization server, then run its first SQL command while that server is shutting down. This failed the static job on infra#247 with a missing socket before the new acceptance tests ran.Probe127.0.0.1 over TCP instead: the initialization server has TCP disabled, so readiness waits for the final server. Keep the existing bounded wait and every role/SQL assertion unchanged.
Validation: bash syntax and
git diff --checkpass. A stateful fake-Docker startup-race fixture reproduces the old prefix exiting2 after temporary-server readiness and the fixed prefix exiting0 after final TCP readiness; no real Docker/target operations. The existing CI test provides the real PostgreSQL integration run.Open in [code]smith · Need help on this PR? Tag
@codesmith-botwith what you need.