[no-release-notes] Release v0.57.3

[coffeegoddd]

Created by the Release workflow to update DoltgreSQL's version

[github-actions]

	Main	PR
covering_index_scan_postgres	2087.33/s	2062.23/s	-1.3%
groupby_scan_postgres	143.35/s	144.64/s	+0.8%
index_join_postgres	675.34/s	673.54/s	-0.3%
index_join_scan_postgres	839.96/s	845.66/s	+0.6%
index_scan_postgres	32.54/s	32.84/s	+0.9%
oltp_delete_insert_postgres	870.34/s	857.75/s	-1.5%
oltp_insert	740.72/s	720.48/s	-2.8%
oltp_point_select	3429.11/s	3457.53/s	+0.8%
oltp_read_only	3423.94/s	3460.12/s	+1.0%
oltp_read_write	2628.38/s	2619.11/s	-0.4%
oltp_update_index	790.10/s	774.89/s	-2.0%
oltp_update_non_index	848.59/s	800.86/s	-5.7%
oltp_write_only	1860.59/s	1872.37/s	+0.6%
select_random_points	2124.17/s	2166.23/s	+1.9%
select_random_ranges	1616.06/s	1625.53/s	+0.5%
table_scan_postgres	31.71/s	32.20/s	+1.5%
types_delete_insert_postgres	824.48/s	823.30/s	-0.2%
types_table_scan_postgres	14.39/s	14.54/s	+1.0%

[itoqa]

Commit: f4bc507: 10 test cases ran, 8 passed ✅, 2 additional findings ⚠️.

Summary

Coverage spans release identity and runtime behavior across clean starts, restarts, retries, in-memory operation, persistent data, service readiness, and secure connections. It also probes release packaging edge cases, including source builds and protection against shipping an older executable, with the application behavior otherwise healthy across the exercised flows.

Safe to merge — the failures identify pre-existing release-build and packaging weaknesses, and none are attributable to this PR’s version change. These remain important follow-up findings, including a high-severity risk of publishing stale binaries, but they are not merge blockers for this change.

Tests run by Ito

Result	Severity	Type	Description
✅	—	Release	The source-built binary reports Doltgres version 0.57.3, matching the expected release and replacing the older 0.57.1 value.
✅	—	Runtime	A clean local data directory started successfully, accepted a database query, and reported Doltgres version 0.57.3.
✅	—	Runtime	The embedded server started with empty user settings, accepted a secure connection, and completed database operations successfully.
✅	—	Runtime	The server restarted with the same data directory, accepted a query before and after the restart, and kept reporting release 0.57.3.
✅	—	Runtime	After an initial setup failure, correcting the data path allowed the server to start, accept a database query, and report Doltgres version 0.57.3.
✅	—	Service	A new local service started, accepted a PostgreSQL connection, and reported release 0.57.3 while the default postgres database was available.
✅	—	Service	After a restart, the existing local environment stayed usable, preserved its fixture row, and returned release 0.57.3.
✅	—	Service	The server accepted a secure PostgreSQL connection using TLS 1.3 and returned release 0.57.3. The existing database fixture was still available.
⚠️		Release	The pinned 0.57.3 image reported the expected version, but an image containing 0.57.1 also built successfully and ran successfully. A stale executable should have stopped the image build before publication.
⚠️		Release	The source-build option fails before it creates a Docker image. It should compile the current source and produce a runnable image that reports the current release, but the build stops because its Go tool is older than the version required by the project.

Additional Findings Details

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

🟠 Older binary can ship in release image

• Severity: High
• Description: The pinned 0.57.3 image reported the expected version, but an image containing 0.57.1 also built successfully and ran successfully. A stale executable should have stopped the image build before publication.
• Impact: Users downloading a new release may receive an older executable that lacks the release's fixes and features, even though the download appears successful. The wrong executable can remain available until the published artifact is replaced.
• Steps to Reproduce:
  1. Build the image with an explicit release selection of 0.57.3 and check the binary version during the build and from the completed image.
  2. Build the same image through the download path with an older downloaded artifact, such as 0.57.1, while expecting the selected release to be checked.
  3. Observe that the image build succeeds and the completed image runs the older binary instead of rejecting it.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The explicit-version branch in /tmp/output-agent-workspace/repo/Dockerfile:40-43 constructs the release install URL from DOLTGRES_VERSION and pipes install.sh into the shell, but it does not pass an expected version to the installer or validate the installed file afterward. The runtime stage at Dockerfile:48-51 copies the binary and runs /usr/local/bin/doltgres --version only as an executable smoke check; it never captures the output or compares it with DOLTGRES_VERSION. The installer path at /tmp/output-agent-workspace/repo/scripts/install.sh:102-112 downloads the archive, extracts it, and installs the contained binary without checking its embedded release identity. Therefore an executable archive whose contents are stale or mislabeled can satisfy every current build check and be published. The smallest practical fix is to add a post-install equality check for the requested version in the downloaded-image path, failing the build when the binary output does not match DOLTGRES_VERSION. The PR diff in server/server.go changes only the compile-time Version constant at line 51 and does not modify any of these paths.

Evidence Package

• text/RELEASE-3/RELEASE-3-stale-download-evidence.txt — 3 KB

🟡 Source build cannot create Docker image

• Severity: Medium
• Description: The source-build option fails before it creates a Docker image. It should compile the current source and produce a runnable image that reports the current release, but the build stops because its Go tool is older than the version required by the project.
• Impact: Operators cannot build a runnable image from the current source through the documented Docker path. This blocks source-based releases until the build tool version is updated.
• Steps to Reproduce:
  1. Run docker build --target build-from-source --build-arg DOLTGRES_VERSION=source -t doltgres-release-source:qa . from the repository root.
  2. Allow the source-build stage to run its Go module download and binary build commands.
  3. Observe that the build stops because the selected Go tool is version 1.25.12 while the module requires Go 1.26.2, so no image or runtime binary is produced.
• Stub / mock content: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code Analysis: The source path is selected by the DOLTGRES_VERSION=source argument in /tmp/output-agent-workspace/repo/Dockerfile:20. That stage starts from golang:1.25-trixie at Dockerfile:12, then Dockerfile:21-24 runs go mod download, the parser build, the binary build script, and moves the generated binary into /usr/local/bin. The module declaration at /tmp/output-agent-workspace/repo/go.mod:3 requires Go 1.26.2, so the Go 1.25.12 toolchain in the Docker image rejects the module before compilation. The recorded build output reports go.mod requires go >= 1.26.2 (running go 1.25.12; GOTOOLCHAIN=local), followed by the expected missing-output error at the move step. The smallest practical fix is to update Dockerfile:12 to a Go image that satisfies the go.mod requirement, such as golang:1.26-trixie, and then rerun the source image build.

Evidence Package

• text/RELEASE-2/RELEASE-2-source-build-failure.txt — 910 B

Tip

Reply with @itoqa to send us feedback on this test run.

[github-actions]

	Main	PR
Total	42090	42090
Successful	18868	18868
Failures	23222	23222
Partial Successes1	5326	5326

	Main	PR
Successful	44.8278%	44.8278%
Failures	55.1722%	55.1722%

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. ↩