Context
We build portable host-native archives of supabase/postgres (nix flake build) over in supabase/slim-services, and gate every artifact on a measured glibc floor — the maximum GLIBC_2.x version requirement (ELF Verneed) across all shipped ELFs, i.e. the oldest host glibc the artifact can run on.
Observation
On 17.6.1.143, the whole artifact's floor is set by a single extension — wrappers (pgrx):
| target |
max-Verneed offender |
floor |
| linux-arm64 |
lib/wrappers-0.6.2.so |
GLIBC_2.39 |
| linux-amd64 |
lib/wrappers.so |
GLIBC_2.39 |
Everything else in the artifact (223 ELFs scanned, including the postgres binary and all other extensions) needs at most GLIBC_2.38. So the pgrx toolchain in the flake is the one thing pinning consumers to Ubuntu 24.04-class hosts (glibc ≥ 2.39); at 2.38 the same artifact would also cover Ubuntu 23.10 / Fedora 39-class hosts, and lower would widen further (e.g. RHEL 9 at 2.34).
Ask
Would you consider having the flake's Rust/pgrx toolchain target a lower glibc link floor? Typical options, in rough order of invasiveness:
- build pgrx extensions with a slightly older nixpkgs stdenv/glibc than the rest (only the cdylib link matters), or
- use a toolchain that pins the glibc symbol ceiling explicitly (e.g.
cargo-zigbuild-style --target <arch>-unknown-linux-gnu.2.34).
No urgency and no coordination needed on our side either way: our per-service floors are measured per build from the artifacts themselves, so any improvement in the flake lands automatically the next time we bump the postgres version.
If there's a constraint that makes 2.39 deliberate (e.g. a runtime dependency of wrappers needing newer symbols), happy to have that recorded here instead — we'll keep gating at 2.39 for postgres in that case.
Context
We build portable host-native archives of supabase/postgres (nix flake build) over in supabase/slim-services, and gate every artifact on a measured glibc floor — the maximum
GLIBC_2.xversion requirement (ELF Verneed) across all shipped ELFs, i.e. the oldest host glibc the artifact can run on.Observation
On
17.6.1.143, the whole artifact's floor is set by a single extension —wrappers(pgrx):lib/wrappers-0.6.2.solib/wrappers.soEverything else in the artifact (223 ELFs scanned, including the
postgresbinary and all other extensions) needs at most GLIBC_2.38. So the pgrx toolchain in the flake is the one thing pinning consumers to Ubuntu 24.04-class hosts (glibc ≥ 2.39); at 2.38 the same artifact would also cover Ubuntu 23.10 / Fedora 39-class hosts, and lower would widen further (e.g. RHEL 9 at 2.34).Ask
Would you consider having the flake's Rust/pgrx toolchain target a lower glibc link floor? Typical options, in rough order of invasiveness:
cargo-zigbuild-style--target <arch>-unknown-linux-gnu.2.34).No urgency and no coordination needed on our side either way: our per-service floors are measured per build from the artifacts themselves, so any improvement in the flake lands automatically the next time we bump the postgres version.
If there's a constraint that makes 2.39 deliberate (e.g. a runtime dependency of wrappers needing newer symbols), happy to have that recorded here instead — we'll keep gating at 2.39 for postgres in that case.