[auto-bump] [no-release-notes] dependency by angelamayxie

[coffeegoddd]

☕ An Automated Dependency Version Bump PR 👑

Initial Changes

The changes contained in this PR were produced by `go get`ing the dependency.

```bash
go get github.com/dolthub/[dependency]/go@[commit]
```

[itoqa]

Ito Test Report ✅

8 test cases ran. 1 additional finding, 7 passed.

Overall, 7 of 8 tests passed, confirming stable SQL engine behavior (startup to ReadyForQuery, successful probe queries, and controlled malformed-SQL errors without session crashes), reliable storage initialization and restart persistence, successful auth-file transition restart recovery, and clean module/Linus build reproducibility. The key issue is one high-severity deterministic build defect: windows-amd64 packaging fails because go:embed in the Windows extension loader references missing files (core/extensions/pg_extension/output/postgres.exe and pg_extension.dll), blocking Windows release artifacts, and several runtime/auth scenarios were executed under intentional local auth/SCRAM bypasses so real credential enforcement was not validated.

✅ Passed (7)

Category	Summary	Screenshot
Auth	Validated near-simultaneous restart around auth file creation completed without panic and recovered to ready state under controlled auth bypass conditions.
Build	Module download, test suite, and binary build completed successfully.
Build	Linux release build produced the expected binary and tar archive outputs.
Engine	Using local fallback doltgres on 5432, PostgreSQL startup/auth completed and SELECT 1 returned probe=1 without protocol errors.
Engine	Malformed SQL produced controlled syntax errors and did not crash the service; valid follow-up queries succeeded in both same and separate sessions.
Storage	Started doltgres against a fresh empty data directory, then confirmed default database creation and queryability (pg_database listed postgres and current_database() returned postgres).
Storage	Created and persisted table data, performed clean stop/restart against the same data directory, then verified persisted row and database listing remained available after restart.

ℹ️ Additional Findings (1)

These findings are unrelated to the current changes but were observed during testing.

Category	Summary	Screenshot
Build	⚠️ Windows build cannot produce release artifacts because required embedded files are missing from the repository.

⚠️ Windows build fails on missing embedded assets

• What failed: The Windows release flow expects doltgres.exe and Windows archives, but build fails before artifact output because go:embed references output/postgres.exe and output/pg_extension.dll that are not present.
• Impact: Windows release artifacts cannot be produced from this repository state, so Windows distribution for this build pipeline is blocked. Teams relying on windows-amd64 outputs have no practical workaround in the current source tree.
• Steps to reproduce:
  1. Run scripts/build_binaries.sh windows-amd64.
  2. Allow the script to execute go build ./cmd/doltgres for the windows target.
  3. Observe that compile/embed resolution fails because output/postgres.exe and output/pg_extension.dll are not present under core/extensions/pg_extension/output/.
• Stub / mock context: The run attempted the real windows-amd64 build command and then verified the failure directly in source code paths; no API mocking or route interception was used for this build-path verification.
• Code analysis: I inspected the Windows loader embed declarations and the release build script path used for windows-amd64. The build script always compiles ./cmd/doltgres, which includes the Windows-only embed file that requires assets under core/extensions/pg_extension/output/, but that directory is absent in the repo.
• Why this is likely a bug: The production build path deterministically references embedded Windows files that do not exist in the repository, so Windows compilation fails independently of test harness behavior.

Relevant code:

core/extensions/pg_extension/library_loader_windows.go (lines 34-40)

// PLATFORM specifies which platform applies to the current library loader. This will always be a three-letter string.
const PLATFORM = "WIN"

//go:embed output/postgres.exe
var libDefBytes []byte

//go:embed output/pg_extension.dll
var dllBytes []byte

scripts/build_binaries.sh (lines 75-89)

if [ "$os" = windows ]; then
      bin="$bin.exe"
  fi
  echo Building "$o/bin/$bin"
  CGO_ENABLED=1 \
      GOOS="$os" \
      GOARCH="$arch" \
      CC="${platform_cc[${tuple}]}" \
      CXX="${platform_cxx[${tuple}]}" \
      AS="${platform_as[${tuple}]}" \
      CGO_LDFLAGS="${platform_cgo_ldflags[${tuple}]}" \
      go build -buildvcs=false -trimpath \
      -ldflags="${platform_go_ldflags[${tuple}]}" \
      -tags icu_static -o "$o/bin/$bin" \
      ./cmd/doltgres

Commit: 26429a7

View Full Run

---

Tell us how we did: Give Ito Feedback

[github-actions]

	Main	PR
Total	42090	42090
Successful	18197	18197
Failures	23893	23893
Partial Successes1	5392	5392

	Main	PR
Successful	43.2335%	43.2335%
Failures	56.7665%	56.7665%

Footnotes

1. These are tests that we're marking as Successful, however they do not match the expected output in some way. This is due to small differences, such as different wording on the error messages, or the column names being incorrect while the data itself is correct. ↩