fix: address Windows, NixOS, and localhost startup issues (#9 #10 #11)#12
Merged
nicoloboschi merged 2 commits intomainfrom Apr 24, 2026
Merged
fix: address Windows, NixOS, and localhost startup issues (#9 #10 #11)#12nicoloboschi merged 2 commits intomainfrom
nicoloboschi merged 2 commits intomainfrom
Conversation
- Windows (#9): extract theseus-rs ZIP bundle via the zip crate (was failing with "invalid gzip header"), add Windows to the pgvector platform map so pg0-windows-x86_64.exe ships with pgvector, and pick the right .exe-suffixed binary names. - NixOS (#11): pin timezone/log_timezone to UTC so PostgreSQL never reads /usr/share/zoneinfo at startup (the upstream binaries are compiled against Debian's tzdata path, which does not exist on NixOS). - Localhost (#10): use 127.0.0.1 in all generated connection URIs and client calls, avoiding DNS/host-resolution variance for localhost. Other: - drop pgbouncer from versions.env (never referenced in build.rs or main.rs, so it was dead config). - CI: add build-windows + sdk-tests-windows jobs that mirror the release-cli.yml compile step (same toolchain targets, same cargo invocation, same artifact path) and run the full pytest suite on windows-latest. Skip the SIGKILL crash-recovery test on Windows since signal.SIGKILL does not exist there.
On Windows, `pg0 start` spawns PostgreSQL which inherits pg0's stdio handles. pg0 exits promptly (PG is intentionally detached via std::mem::forget), but PostgreSQL keeps writing to the inherited handles, so Python's `subprocess.run(capture_output=True)` never sees pipe EOF and hangs indefinitely. Unix is unaffected — `pg_ctl` closes inherited FDs before handing off to postgres. Route stdio through real temporary files on Windows. subprocess.call only waits on the process exit code, not on file handles held by grandchildren, so pg0 returns as soon as it exits regardless of what PostgreSQL does with the inherited file handles afterwards. Also add a 20-minute timeout-minutes to the sdk-tests-windows CI job so future hangs fail fast instead of consuming 6h of runner time.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Addresses all three open issues:
src/main.rs: pintimezone/log_timezonetoUTCso PostgreSQL never reads the bundled-binary's hardcoded/usr/share/zoneinfopath at startup.src/main.rs+ SDK READMEs: use127.0.0.1in generated connection URIs. Removes DNS/host-resolution variance.Cargo.toml: addzipcrate as acfg(windows)dep.src/main.rs: splitextract_postgresql_archiveinto tar.gz (non-Windows) and ZIP (Windows) impls. theseus-rs ships the Windows PostgreSQL bundle as.zip; the previous code tried toGzDecoderit and failed with invalid gzip header. Also fixesPOSTGRES_BINARY/psqlto use the.exesuffix on Windows.build.rs: wirex86_64-pc-windows-msvcinto the pgvector platform map (pgvector is available for Windows atnicoloboschi/pgvector_compiled).Other
PGBOUNCER_*fromversions.env— it was declared but never referenced anywhere inbuild.rsormain.rs.build-windows+sdk-tests-windowsjobs inci.yml. The build step mirrors therelease-cli.ymlWindows step exactly (same toolchain target, samecargo build --release --target x86_64-pc-windows-msvc, same artifact path) so CI exercises the real release compile path. The Python SDK tests runpytest tests/onwindows-latest. The existing coverage was only a minimal start/stop smoke test inside the wheel-build workflow.test_data_survives_crashnow skips on Windows becausesignal.SIGKILLdoesn't exist there.Test plan
cargo checkon host (aarch64-apple-darwin)cargo check --target x86_64-pc-windows-gnubuild-windowsproducespg0.exesdk-tests-windowsruns the full pytest suite onwindows-latest