Repository navigation
Conversation
Guards against binaries silently requiring a newer glibc than customer AMIs ship. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Runs as checks.<system>.glibc-floor, auto-discovered by the existing nix-eval matrix generator, so no workflow changes are needed. Scans every legacyPackages derivation instead of one step per matrix leg. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Same find/objdump/version-compare logic, packaged via pkgs.writers.writeNuBin. Verified standalone against a fake objdump (pass/fail/no-match cases) since the local linux-builder VM's clock is currently skewed and blocking real nix builds unrelated to this change. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Drop the single-worst summary line; print one line per file that exceeds the floor (deduped to its own worst symbol version), plus a short pass line when nothing offends. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
PostgreSQL Extension Dependency Analysis: PR #2437
SummaryNo extensions had dependencies with MAJOR version updates. Full Analysis ResultsPostgreSQL 15 Extension DependenciesPostgreSQL 17 Extension DependenciesOrioleDB 17 Extension Dependencies |
PostgreSQL Package Dependency Analysis: PR #2437
SummaryNo packages had MAJOR version updates. Full Analysis ResultsPostgreSQL 15 Dependency ChangesExtracting PostgreSQL 15 dependencies...
Runtime Closure Size
Raw Dependency ClosurePostgreSQL 17 Dependency ChangesExtracting PostgreSQL 17 dependencies...
Runtime Closure Size
Raw Dependency Closure |
Print offenders as a table instead of hand-formatted strings, run
objdump via par-each, drop the do{}/exit_code plumbing (a failing
objdump naturally yields no stdout, so it's already filtered out).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
packages is missing site-extensions-versions-* and only exposes flat psql_X/bin (not individual .exts.*), so union both trees rather than choosing one and risking a coverage gap. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Packages contain far more non-ELF files (docs, control files, SQL, scripts) than ELF ones. Checking the magic bytes natively in nushell avoids spawning an objdump process per file that could never match. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
is-elf now guards its own path-type check, collapsing the two where clauses into one. Also tried adding a `-> list<int>` return type to ver-key, but nushell's static checker rejects `>` on that type even though it works fine at runtime on inferred lists, so left it untyped. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
[] | last returns null rather than erroring, so building the record unconditionally and filtering null versions out in one where clause replaces the separate if/else + compact step. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Renamed away from "floor" terminology (the function computes each file's max required glibc version, not a floor) across the nix check attribute, script filename, and its docstring/output text. Also rewrote the check logic itself in idiomatic nushell: is-elf and max-glibc-version as named helpers, ELF detection via magic-byte check (skips non-ELF files instead of shelling out to objdump for every file), version comparison via parsed int lists, and offending files printed as a table. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
brainrake
marked this pull request as ready for review
September 14, 2026 09:08
brainrake
changed the title
Collaborator
|
There's no explanation for why we want to have this functionality. It also seems to me that we use libc from nix for most binaries so this enforcement doesn't make sense in those cases right? |
Collaborator
|
Also https://github.com/fzakaria/sqlelf is worth a look too ;) |
brainrake
marked this pull request as draft
September 14, 2026 19:54
Collaborator
Author
|
@mmlb updated description to show why we need this. It's a tricky one. |
brainrake
marked this pull request as ready for review
September 17, 2026 17:05
brainrake
marked this pull request as draft
September 17, 2026 17:06
brainrake
marked this pull request as ready for review
September 18, 2026 01:06
This comment has been minimized.
This comment has been minimized.
brainrake
marked this pull request as draft
October 2, 2026 17:29
auto-merge was automatically disabled
October 2, 2026 17:29
Pull request was converted to draft
2.40 is the glibc in the oldest AMI build (17.6.1.072) sharing current collation data, the oldest version safely migratable without risking collation-driven data corruption. Supautils targets 2.31 separately. Refs: MPG-126
Extensions and site-env still target 2.31, supautils's compat floor. Refs: MPG-126
This was referenced Oct 5, 2026
…le as core They just repackage an already core-targeted postgres build rather than compiling anything themselves, so they belong in the 2.40 bucket, not the 2.31 catch-all. Refs: MPG-126
…tekeeper Extensions only ever activate within the same AMI's own nix closure (via postgres_prestart.sh's switch_<ext>_version), so they already share core's glibc floor — there's no live path that pushes a newer build onto an older host. The one exception is anything loaded outside that closure: supautils via session_preload_libraries into an already-running legacy postgres, and gatekeeper via the host's system PAM stack. Both keep the deeper 2.31 (Ubuntu 20.04) floor; everything else now checks against core's 2.40. Refs: MPG-126
Core and extensions always share one glibc from the same build closure, so glibc-version-check now only covers supautils and gatekeeper (loaded outside that closure, reachable from older hosts). collation-version-check pins glibc's version against collation-version-baseline.txt and fails CI on drift, requiring a deliberate, reviewed baseline bump instead of a silent collation change riding in on a nixpkgs input bump. Refs: MPG-126
brainrake
changed the title
brainrake
changed the title
brainrake
marked this pull request as ready for review
October 5, 2026 22:55
version was still the parsed int list used for comparison, printing as "[list 2 items]" instead of e.g. "2.34". Refs: MPG-126
…0e746' into claude/glic-reporting-workflow-60e746
Pure string comparison, no build needed — fails nix eval/flake check immediately with the message, instead of a derivation you have to build and open logs for. Refs: MPG-126
This comment has been minimized.
This comment has been minimized.
…mpty lib.collect only recurses into attrsets (see lib/attrsets.nix), so wrapping an already-flat list in it silently returns []. supautils wasn't even in self'.packages (it only exists per-PG-version under legacyPackages.psql_X.exts.supautils), so the check was vacuously passing for both exceptions. Now genuinely checks gatekeeper and supautils (all 3 PG majors) against 2.31 — both currently fail (tracked in MPG-1326). Refs: MPG-126
gatekeeper's first commit (8808138, "custom pam" #1772) already pinned postgres_release 17.6.1.072 — the same AMI generation postgres core's own 2.40 floor is set to. It's installed at AMI-build time (ansible/tasks/stage2-setup-postgres.yml, a Packer/ebssurrogate provisioning task), never retrofitted onto an older running host, so it's never actually reached anything below 2.40. Only supautils (dlopened into already-running legacy pre-nix postgres) still needs the lower floor. Refs: MPG-126
brainrake
added a commit
that referenced
this pull request
Oct 6, 2026
Everything previously here (shim wiring for orioledb, supabase-groonga, pgbouncer, pgbackrest; CGO_ENABLED=0 for goss, packer) addressed packages that turned out not to need a glibc floor: postgres core and every extension share one glibc from the same build closure, so glibc-version-check no longer checks them (see #2437). Neither this nor the removed changes ever touched supautils or gatekeeper, the two packages that actually still fail the 2.31 floor (MPG-1326) since they're loaded outside that closure. Repurposing this branch to fix those instead. Refs: MPG-1326
brainrake
changed the title
It's dlopened by the base AMI's own system PAM stack, not postgres's nix closure, so it isn't covered by "core and extensions share one glibc" — a future nixpkgs glibc bump could silently outrun the base image's own system glibc within the same AMI build. Pin it explicitly rather than relying on that happening to hold. Refs: MPG-126
brainrake
changed the title
…ing-workflow-60e746
|
Found 1 test failure on Blacksmith runners: Failure
|
![Fix with [code]smith](https://pr-comments-assets.blacksmith.sh/codesmith/fix-with-codesmith-light.svg)
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
2 participants
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.
Why
supautils is dlopened via
session_preload_librariesinto already-running legacy postgres, so it needs a much lower glibc floor than anything else. gatekeeper is dlopened by the base AMI's own system PAM stack, not postgres's nix closure, so a future glibc bump could silently outrun the base image. Separately, a glibc bump can silently change collation data without a version-string change, corrupting existing indexes.What
glibc-version-check: supautils at 2.31 (Ubuntu 20.04), gatekeeper at 2.40 (current core floor). Everything else shares postgres core's own glibc from the same build closure, so needs no floor.collation-version-check: eval-time assertion pinning glibc's version; fails on drift so a bump is a deliberate, reviewed act.Test plan
MPG-126