v3.0.8-magda-edcda8b — PG15+ base backup protocol fix (unreleased upstream)

Custom WAL-G PostgreSQL build for Magda, cut from upstream master because the fix Magda needs is merged upstream but not present in any upstream release.

What this is

Built from	edcda8bb72e7b62750026dae7a6c4c65739355f8 (this fork's master)
Upstream base	newer than v3.0.8 (21 Jan 2026), the latest upstream release
Key commit included	9bcccbd2d2960619ff81cd9a815526626bb74c1d — wal-g/wal-g#2262
wal-g --version reports	v3.0.8-magda-edcda8b edcda8bb PostgreSQL

The version string is 3.0.8-magda-… because v3.0.8 is the newest upstream release this build descends from. The build is newer than v3.0.8, not equal to it.

Why this build exists

Magda is upgrading its bundled PostgreSQL from 13.7 to 17.5. Magda's backup CronJob runs wal-g backup-push without a $PGDATA argument — WAL-G's remote mode, which streams the base backup over PostgreSQL's BASE_BACKUP replication protocol.

PostgreSQL 15 changed the BASE_BACKUP replication-command syntax and stream format. Every released WAL-G version fails against PostgreSQL 17 in remote mode:

WAL-G	Result against PostgreSQL 17.5, remote mode
3.0.8, 3.0.7, 3.0.6	CompressAndEncrypt: compression failed: archive/tar: invalid tar header
3.0.5, 2.0.1, 1.1.0	unexpected response: … 42601 syntax error … repl_scanner.l … replication_yyerror

The same versions succeed against PostgreSQL 13.7, isolating the PostgreSQL major version as the cause. This matches upstream issues #2044, #1385 ("backup-push does not work on the Postgresql 15/16 without $PGDATA in command line") and #2005.

PR wal-g#2262, "Support new base backup protocol introduced in PG15", fixes it. It merged upstream on 22 May 2026 — four months after v3.0.8 was released — and there has been no release since. Upstream's release cadence is irregular (v3.0.7 Apr 2024, v3.0.5 Jan 2025, v3.0.8 Jan 2026), so waiting was not viable.

This release exists solely to make that merged-but-unreleased fix consumable. It should be retired in favour of an upstream release as soon as one contains wal-g#2262.

Verification

Both binaries were tested before publication:

• backup-push (remote mode) against PostgreSQL 17.5 succeeds, then backup-list → backup-fetch → server start on the restored data directory returns all 5000 seeded rows intact.
• No regression against PostgreSQL 13.7, which matters because Magda must keep backing up PG13 instances during the migration window.
• Extraction and sha256sum -c verified on a minideb:bullseye (glibc 2.31) base, the actual runtime environment of the consuming image.

Artifacts

Built on Ubuntu 20.04 (glibc 2.31), matching upstream's wal-g-pg-20.04-* convention, so the binaries run on both minideb:bullseye (glibc 2.31) and Debian 12 bookworm (glibc 2.36).

File	sha256
wal-g-pg-20.04-amd64.tar.gz	59f0672e13d3cb455da90edf4ed0ed14f4728124920b69159552678dd6297566
wal-g-pg-20.04-aarch64.tar.gz	9c13cc49e9252f20b6c34056ebdf146de51fe7a4fd8cc13f26bf634da2ced530

Max glibc symbol required: GLIBC_2.3.4 (amd64), GLIBC_2.17 (aarch64) — both well below the 2.31 ceiling.

Built with CGO_ENABLED=1, GOEXPERIMENT=jsonv2, mirroring the Makefile's pg_build flags. USE_BROTLI / USE_LIBSODIUM / USE_LZO are not set, matching upstream's default release build.

Each .tar.gz contains a single binary named after the archive, and each is accompanied by a .sha256 in sha256sum format — the same layout upstream publishes, so it is a drop-in for consumers that download and verify upstream artifacts.

Consumed by

magda-io/magda-wal-g, which packages the binary into the image used by Magda's magda-postgres chart for base backups, WAL archiving (archive_command), and restore.