Releases: dsub-io/go-open-discogs-batch
Release list
v2.3.12
v2.3.11
v2.3.10
v2.3.9
2.3.9 (2026-08-13)
Performance Improvements
- Consume canonical
open-discogs-modelv0.3.2 and apply V022 before import work starts (#73). - Keep Go and Java migrators on identical canonical migration bytes.
Measured impact
On the model-owned 1,000,000-release fixture, combined-filter SQL p99 decreased from 6.856 ms to 0.225 ms (-96.7%). The plan changed from 4,386 heap blocks plus a top-N sort to an ordered 53-buffer index scan. The index occupies 31,522,816 bytes (+6.5% on the post-V007 test database). Import throughput is unchanged because the writer path did not change.
Upgrade note
V022 builds the index once during schema migration before import processing begins. Allow time and storage for the index build on an existing release table.
v2.3.8
v2.3.7
What changed
- Release workers now lock every affected
masterrow in ascending ID order before writing release roots and reconcilingmain_release_id. - This removes the circular lock ordering that could occur when concurrent chunks referenced overlapping masters.
- Import durability is unchanged: each chunk remains transactional, failed runs remain auditable, and a retry uses idempotent upserts.
Production evidence
The v2.3.6 production import used chunk-size=5000 and max-workers=4. Artist, label, and master imports completed, then release import committed its first 5,000 roots before PostgreSQL reported a four-transaction UPDATE master deadlock. The failed run and committed chunk were retained correctly.
Completed stages before that failure:
- Artist: 10,163,318 roots in 110.80 s (91,729.54 roots/s)
- Label: 2,405,196 roots in 21.98 s (109,416.57 roots/s)
- Master: 2,579,897 roots in 82.01 s (31,459.07 roots/s)
Validation
- Four concurrent release writers targeting four overlapping masters completed without deadlock in 10/10 integration-test runs.
- Full race-enabled test suite passed with exact 100.0% statement coverage.
- PostgreSQL end-to-end import tests passed.
- Test-owned containers, networks, and volumes were removed and verified absent.
Performance note
This is a correctness and forward-progress fix, not a claimed latency or throughput optimization. The lock adds one ordered row-lock query per release chunk. End-to-end throughput and peak memory will be reported from the successful full production retry rather than inferred from the failed run.
Distribution
- Signed release commit:
606e3e78a3d4e4c440e9bbf8cbef6ba506ff2309 - GHCR multi-arch image:
ghcr.io/dsub-io/go-open-discogs-batch:2.3.7 - OCI index digest:
sha256:27a41d4f28050b63378ab934ede0a0ad3fd0884431e54cd1ec1a295a40cb9159 - Image platforms:
linux/amd64,linux/arm64 - Release binaries: Linux, macOS, and Windows for amd64/arm64, with published SHA-256 checksums
v2.3.6
What changed
- Adopted the canonical
open-discogs-modelv0.3.0 migration inventory, checksums, lock, and release relation contract, serializing schema migration ownership across batch implementations. - Rejects unsafe partial Artist/Master/Release resumes before import begins when required dependency checkpoints are missing.
- Deduplicates Release relations only by their canonical PostgreSQL conflict keys. Conflicting payloads for one key now fail explicitly instead of silently choosing first- or last-wins data.
- Preserves
(release_item_id, label_id, catalog_number)as the label relation identity and removes only exact duplicates. - Secured release publishing and kept release commits verifiably signed.
Data evidence
The 2026-08 dump audit streamed all 19,341,287 releases and 22,465,877 label relations. The old two-column label key collided 1,387,721 times: 1,380,015 represented distinct catalog numbers that must be preserved, while 7,706 were exact duplicates.
This is a correctness and durability release. A full production import was intentionally not run before release, so no throughput, latency, or RSS improvement is claimed.
Validation
- Full Go suite passed with the race detector and 100.0% statement coverage.
- PostgreSQL end-to-end import, interruption/recovery, static checks, and release-image verification passed.
- Test containers, networks, and volumes were removed and residue checks passed.
Distribution
- Linux, macOS, and Windows archives plus Linux DEB/RPM/APK packages and checksums are attached below.
- Public OCI image:
ghcr.io/dsub-io/go-open-discogs-batch:2.3.6 - Platforms:
linux/amd64,linux/arm64 - OCI index digest:
sha256:5853fc7fd82641d2cc1f191537e5b698e6fb83371850d2d8f886ab357090abd5 latestpoints to the same validated digest.
v2.3.5
v2.3.4
v2.3.4 — deadlock prevention and terminal-safe progress
This is a bug-fix release for concurrent imports and progress output.
Fixed
- Sort shared genre and style reference inserts so concurrent workers acquire PostgreSQL uniqueness locks in one deterministic order for both Master and Release imports.
- Preserve interactive progress bars on stderr when stderr is a TTY.
- Emit line-delimited
byte_progressJSON on stdout for pipelines and log collectors, without ANSI escapes or carriage returns. - Suppress ANSI-formatted GORM SQL dumps while preserving the bounded error returned at the CLI boundary.
Production recovery
The failure that prompted this release occurred with max-workers=4 after Artist and Label completed. The durable ledger retained Master's first 30,000 items in 6 chunks, so v2.3.4 can resume without rewriting completed entities or requesting Discogs metadata again.
Measured output reduction
Under the same non-TTY logging path:
- Source progress is bounded from up to 4 carriage-return renders per second to 0.2 JSON records per second: 95% fewer progress writes.
- Download progress is bounded from up to 2 renders per second to 0.2 JSON records per second: 90% fewer progress writes.
- TTY progress bars remain enabled and are written to stderr.
Validation
- Race-enabled full suite: 100.0% statement coverage.
- PostgreSQL E2E: passed.
- Docker cleanup verification: no residual test container, network, or volume.
Full change: #60
v2.3.3
2.3.3 (2026-08-12)
Bug Fixes
- Resolve an exact dump month from PostgreSQL before contacting Discogs.
- Reduce uncached 2021+ pinned metadata traffic from two upstream requests to one; cached retries decrease from two to zero.
- Derive all selected dump URIs and SHA-256 values from one monthly checksum document before downloads.
- Stop after the first 429, 5xx, timeout, or malformed modern checksum response without speculative fallback requests.
- Retain the two-request annual catalog path only for pre-2021 irregularly dated dumps.