feat: test against the PostgreSQL 19 beta and refresh pinned tooling

[codegiveness]

Problem

The maintainer asked that the server use and support the latest PostgreSQL and the latest packages and tools. PostgreSQL 19 is not released yet. On 2026-10-11 postgresql.org versions.json listed 13–18 with 18.6 current; the newest announcement was 19 Beta 4 (2026-09-24); and Docker Hub had 19beta1–19beta4 but no 19 or 19rc* tag. Nothing verified the server against 19, and a dependency audit was due.

Behavior change

No server or runtime change (src/ untouched).

• Verifier: POSTGRES_FIXTURE_MAJOR=19 is accepted, pinned to postgres:19beta4-bookworm@sha256:4c618d9a30e0b88078b9371a0499d7055da9ab7f5afe386a460758eac9857f06 (digest read from the registry's Docker-Content-Digest), with HypoPG 1.4.3-1.pgdg12+2, the same version as 13–18. The fixture now stores a tag and a digest for each major. It fails at start if the container's server_version_num major differs from the requested one, so a mislabeled digest cannot silently test a different major.
• CI: the integration matrix gains '19' (Integration (PostgreSQL 19)). It is not a required check. It is not continue-on-error either, so a failure shows on the PR without blocking merges.
• github/codeql-action is bumped from v4.38.2 to v4.38.3 (24c54180a607b1449ed407dd24f251e4e9147c8d, reached by following the annotated tag to its commit) in codeql.yml and scorecard.yml. The release npm job's Node goes from 24.15.0 to 24.21.0 (LTS, 2026-09-07); CONTRIBUTING and the security posture are updated to match.
• README says 19 is tested as a pre-release, with the exact tag, and that 13 remains the minimum. CONTRIBUTING documents the fixture range 13–19 and how to move to 19-bookworm when 19 ships. CHANGELOG has Unreleased entries.

Version audit (2026-10-11)

Already at the latest stable and left unchanged:

• .NET SDK 10.0.401 (runtime 10.0.12), and the Dockerfile's sdk:10.0/runtime:10.0 digests
• Npgsql 10.0.3, ModelContextProtocol 2.2.0
• Microsoft.Extensions.* 10.0.12 (11.0 exists only as rc), Microsoft.Extensions.AI.Abstractions 10.10.1, SourceLink 10.0.401
• SharpFuzz 2.3.0, FsCheck 3.4.0, CycloneDX 6.2.0, sharpfuzz.commandline 2.3.0
• every other pinned action, npm 12.2.0, Gitleaks 8.30.1, Trivy 0.75.0, actionlint 1.7.12, libfuzzer-dotnet v2025.05.02.0904

dotnet list package --vulnerable --include-transitive reported nothing for all 8 projects. No lock file, notice or license changed.

One item is deliberately not updated: FSharp.Core 5.0.2. It is a transitive dependency of FsCheck, at FsCheck's declared minimum, and is used only by the Verify tool, which is not shipped.

Compatibility and security impact

None for users. 19 is documented as a tested pre-release, not a support commitment. The workflow changes are one action SHA bump and the Node pin; permissions and triggers are unchanged. The codeql-action bump applies to both the baseline and candidate scans in the same run, so the raw-SARIF gate still compares like with like. Making the 19 job required is a ruleset change that only the owner can make.

Evidence

Local, Linux x64, .NET SDK 10.0.401, Docker 29.1.3:

Command / scenario	Result
POSTGRES_FIXTURE_MAJOR=<m> dotnet run --project tools/PostgreSqlMcp.Verify -c Release -- integration	ALL MCP INTEGRATION SCENARIOS PASSED on 19beta4 (4 runs), 18 (3), 17, 16, 15, 14, 13
dotnet restore postgresql-sharp-mcp.slnx --locked-mode	passed
dotnet build postgresql-sharp-mcp.slnx -c Release --no-restore -warnaserror	0 warnings, 0 errors
release-regressions, sarif-regressions	passed
PostgreSqlMcp.Build -- package, then Verify -- packages --artifacts artifacts/packages	passed on 17 and on 19
docker build --pull . then docker run … --version	postgresql-sharp-mcp 0.5.0.0
actionlint 1.7.12 (checksum-verified)	no findings
codeql-action v4.38.3 tag → commit; Node 24.21.0 in nodejs.org index.json	24c54180…; LTS, 2026-09-07

One earlier batch exited 1 for 19 and 18 while other worktrees were running Docker fixtures at the same time. See "Flake diagnosis" below.

Review, merge with main and re-run (2026-10-11)

An AI coding agent reviewed this PR under the maintainer's authorization for the release task. This is not a human review. It read the whole diff, including the ci.yml, codeql.yml, scorecard.yml and release.yml changes line by line. Permissions, triggers, persist-credentials and the base/candidate SARIF setup are unchanged; the codeql-action bump applies to both scans in the same run. It re-checked the pins against upstream:

• v4.38.3 is an annotated tag whose commit is 24c54180a607b1449ed407dd24f251e4e9147c8d.
• Node 24.21.0 is in nodejs.org index.json (2026-09-07, LTS).
• 19beta4-bookworm and 18-bookworm return the pinned Docker-Content-Digest; 19rc1-bookworm returns 404.

No credentials, real connection strings, database output or generated artifacts are in the diff.

origin/main (with #66 and #67) was merged in. Two files conflicted:

• PostgresFixture.cs: feat!: verify TLS by default, measure coverage, make packages reproducible and propose Silver answers #67 added a shared PostgresFixture.Image, which the new TlsFixture uses, while this PR replaced the digest table with tag/digest pairs. The resolution keeps Image and builds it from this PR's table, so the TLS scenarios also run on 19beta4.
• CHANGELOG.md: main's entries come first.

The roadmap range and the pg_stat_statements comment now include 19.

Local re-run after the merge, on 3ea7ab5 (Linux x64, SDK 10.0.401, Docker 29.1.3):

Command	Result
dotnet build postgresql-sharp-mcp.slnx -c Release -p:RestoreLockedMode=true	0 warnings, 0 errors
dotnet format style … --verify-no-changes --no-restore --severity warn	exit 0
POSTGRES_FIXTURE_MAJOR=19 / 18 / 17 … -- integration	ALL MCP INTEGRATION SCENARIOS PASSED on each; 25 PASS lines, including the 3 TLS scenarios

Flake diagnosis

What happened: the failing batch ran for m in 19 18 17 13 sequentially on 2026-10-11 between 02:41 and 02:47 UTC, piped through grep -E "FAIL|ALL MCP|error|warn|Unhandled|reports server". The verifier reports a failure on stderr as the VerificationException message (for example docker exited with status N; expected 0. Captured output suppressed … or Verification failed (<type>) …) and exits 1. None of those messages contains a word the case-sensitive filter matched, so the cause was filtered out and cannot be recovered.

What the surviving lines show:

• 19 printed the privileged-login … PASS line and then exited 1. It failed in one of the last scenarios, after the fixture, HypoPG install and most scenarios had worked.
• 18 printed no line at all. The batch took 366 s (02:41:12 to 02:47:18), and one full run takes about 2 minutes, so 19, 17 and 13 account for nearly all of it. 18 therefore failed within seconds, before any scenario ran.

Two separate failure points rule out a single deterministic defect.

18: fixture start without a cached image. The Docker daemon's journal on this VM begins at 02:32:37 UTC that day. It records every completed pull: 17 at 02:35:59, 19beta4 at 02:37:03, 13 at 02:45:54, and 18 only at 02:50:26, after the batch had ended. A pull by digest happens only when the image is absent, so 18 was not cached during the batch. The 18 run's docker run had to pull the image and failed fast without completing the pull. The verifier suppresses docker run output (Captured output suppressed to protect credentials), so the registry or network error is not recorded, even unfiltered. It was not a timeout (the fixture allows 180 s) and not Docker Hub's rate limit (the anonymous limit read now is 100 per hour, and only three pulls completed in that hour). A cold pull of the same digest now takes 14 s. The PR's apt-get suspicion does not fit: apt-get runs only after the container has started. [INFERENCE] The likely cause is a transient registry or network failure on the first pull.

19: late failure with the image cached. This run passed fixture start, HypoPG installation and most scenarios before failing.

Concurrent load at the time, from the session transcripts and the Docker daemon log: three other agent sessions on the same VM were building the solution and running a coverlet-instrumented coverage run, the TLS integration suite (with its extra TLS containers) and package verification. The daemon log shows postgresql-sharp-mcp-verify-* and -verify-tls-* containers from other worktrees starting throughout 02:41–02:48.

Reproduction attempts on 2ba130e, all with full logs:

Scenario	Runs	Result
4 concurrent integration runs in separate worktrees (two on 19, two on 18), 3 rounds	12	12/12 ALL MCP INTEGRATION SCENARIOS PASSED
19 and 18 concurrently while 32 busy loops saturate the 16 vCPUs, 2 rounds	4	4/4 passed
After the merge, sequential 19/18/17 (table above)	3	3/3 passed
Hosted Integration (PostgreSQL 19) and (PostgreSQL 18) on 2ba130e	2	passed

Conclusion: neither failure reproduces in 19 further local runs (under heavier concurrency and CPU saturation), nor in hosted CI. The 18 failure is explained by an uncached image whose first pull failed; that is an environment failure, not a defect in this branch. Hosted runners start with an empty cache, but the hosted 18 and 19 jobs pulled successfully. For the 19 failure, the most plausible cause is contention from the three concurrent sessions hitting one of the deadline-bound scenarios (request deadlines, pool churn, cancellation within 10 s) [INFERENCE: its failure text is unrecoverable, so this is not proven]. No product or fixture code was changed for either. If it recurs, capture the run's stderr unfiltered; the failing check's message is printed there.

Not verified: the release workflow with Node 24.21.0 (it runs at the 0.6.0 release); HypoPG for 19 on arm64.

Authorship

Written by an AI coding agent (Claude Code) for the maintainer to review.

Checklist

• Title follows the commit format in docs/git-workflow.md
• Affected docs, help and CHANGELOG.md updated
• No credentials, real connection strings, customer SQL or database results anywhere in the change or this description
• Workflow changes (if any) pin actions to full commit SHAs and keep least-privilege permissions

[codegiveness]

Review (AI coding agent under the maintainer's authorization for this task; not a human review). I read the whole diff and the workflow changes line by line, and re-verified the pins upstream: the codeql-action v4.38.3 tag resolves to commit 24c54180…, Node 24.21.0 is LTS in nodejs.org index.json, and the 19beta4/18 manifest digests match the registry. I found no credentials, connection strings, database output or generated artifacts. I merged main after #66/#67; the conflict in PostgresFixture.cs was resolved so the TLS fixture uses this branch's tag/digest table. Local 19/18/17 integration passed after the merge. Hosted on 3ea7ab5: every workflow succeeded, including Integration (PostgreSQL 19) (run 38113954154: ALL MCP INTEGRATION SCENARIOS PASSED, 25 PASS lines including TLS). The flake diagnosis is in the description: the 18 failure came from fixture start without a cached image (the first 18 pull completed only after the batch ended); the 19 failure is unrecoverable, and 19 further runs under heavier concurrency and CPU saturation did not reproduce it.