Skip to content

fix(systemd): ship a unit for the WAL streamer (#56) + dependency bumps - #61

Closed
postgresql007 wants to merge 9 commits into
mainfrom
fix/56-wal-stream-systemd-unit
Closed

postgresql007 wants to merge 9 commits into
mainfrom
fix/56-wal-stream-systemd-unit

Conversation

@postgresql007

Copy link
Copy Markdown
Contributor

Fixes #56, and brings in the four open Dependabot PRs.

#56 — the WAL streamer had no systemd unit

@marsqd was right, and the problem was worse than "a file is missing".

pg_hardstorage.service and pg_hardstorage@.service both run
pg_hardstorage agent, which executes the scheduled backup and retention
engine. It never opens a WAL stream — internal/agent contains no reference
to one. Meanwhile the getting-started tutorial, the R1 runbook and all three
migration guides told operators to supervise the streamer with those units.

An operator who followed the tutorial got periodic base backups and no
continuous archiving
, with nothing to indicate the always-on data plane was
absent. The R1 runbook was worse: systemctl stop pg_hardstorage to "stop the
streamer" would have left the slot held and PostgreSQL still blocked — the
exact failure that runbook exists to resolve.

Added deploy/systemd/pg_hardstorage-wal-stream@.service, templated on the
deployment (wal stream takes it as a positional, so %i genuinely selects
one — unlike the agent template, whose ExecStart ignores %i). Packaged by
all four recipes: goreleaser/nfpm, debian/rules, Arch PKGBUILD, RPM spec.

Corrected the tutorial (now with an explicit "this is not the agent unit"
warning), the R1 runbook, and the three migration guides — each of which
promised a replication slot and then enabled the agent. Three runbooks also
named pg_hardstorage-agent, a unit no package has ever shipped.

Tests now bind the units to the CLI, because nothing did: every unit must
appear in every packaging recipe, every ExecStart must name a verb the CLI
implements, and some unit must run wal stream.

Dependencies (#57-#60)

#57 is the one that matters. grpc 1.83.1 landed four days ago in #55 to clear
an unreachable advisory, and carried a reachable one:

GO-2026-6443  Server panic via missing authority or Host headers
  Fixed in: v1.83.2
  Reachable symbol: transport.http2Server.HandleStreams

govulncheck -mode=binary on the shipped binary: 0 reachable after this
branch, 1 before. Plus the three OTel 1.45.0 bumps (#58, #59, #60).

Verification

  • go build ./cmd/... ./internal/... ./compat/... — clean
  • govulncheck -mode=binary on the release binary — 0 reachable
  • mkdocs build --strict — clean
  • new unit tests pass; systemd-analyze verify reports no syntax errors

Closes #56

dependabot Bot and others added 9 commits September 10, 2026 09:49
Bumps [google.golang.org/grpc](https://github.com/grpc/grpc-go) from 1.83.1 to 1.83.2.
- [Release notes](https://github.com/grpc/grpc-go/releases)
- [Commits](grpc/grpc-go@v1.83.1...v1.83.2)

---
updated-dependencies:
- dependency-name: google.golang.org/grpc
  dependency-version: 1.83.2
  dependency-type: indirect
...

Signed-off-by: dependabot[bot] <support@github.com>
Bumps [go.opentelemetry.io/otel/sdk](https://github.com/open-telemetry/opentelemetry-go) from 1.44.0 to 1.45.0.
- [Release notes](https://github.com/open-telemetry/opentelemetry-go/releases)
- [Changelog](https://github.com/open-telemetry/opentelemetry-go/blob/main/CHANGELOG.md)
- [Commits](open-telemetry/opentelemetry-go@v1.44.0...v1.45.0)

---
updated-dependencies:
- dependency-name: go.opentelemetry.io/otel/sdk
  dependency-version: 1.45.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
…tlptracehttp

Bumps [go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp](https://github.com/open-telemetry/opentelemetry-go) from 1.44.0 to 1.45.0.
- [Release notes](https://github.com/open-telemetry/opentelemetry-go/releases)
- [Changelog](https://github.com/open-telemetry/opentelemetry-go/blob/main/CHANGELOG.md)
- [Commits](open-telemetry/opentelemetry-go@v1.44.0...v1.45.0)

---
updated-dependencies:
- dependency-name: go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracehttp
  dependency-version: 1.45.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
Bumps [go.opentelemetry.io/otel/exporters/otlp/otlptrace](https://github.com/open-telemetry/opentelemetry-go) from 1.44.0 to 1.45.0.
- [Release notes](https://github.com/open-telemetry/opentelemetry-go/releases)
- [Changelog](https://github.com/open-telemetry/opentelemetry-go/blob/main/CHANGELOG.md)
- [Commits](open-telemetry/opentelemetry-go@v1.44.0...v1.45.0)

---
updated-dependencies:
- dependency-name: go.opentelemetry.io/otel/exporters/otlp/otlptrace
  dependency-version: 1.45.0
  dependency-type: direct:production
...

Signed-off-by: dependabot[bot] <support@github.com>
…emetry.io/otel/exporters/otlp/otlptrace/otlptracehttp-1.45.0'

# Conflicts:
#	go.mod
#	go.sum
…emetry.io/otel/exporters/otlp/otlptrace-1.45.0'

# Conflicts:
#	go.mod
#	go.sum
The packages shipped pg_hardstorage.service and pg_hardstorage@.service
— both running `pg_hardstorage agent` — and the documentation told
operators to supervise the WAL streamer with them. The agent runs the
scheduled backup and retention engine and never opens a WAL stream
(grep internal/agent: no reference to it). So an operator who followed
the getting-started tutorial ended up with periodic base backups and
no continuous archiving, and nothing said so.

Adds pg_hardstorage-wal-stream@.service, templated on the deployment
because `wal stream` takes it as a positional, packaged by all four
recipes. Corrects the tutorial, the R1 runbook (whose
`systemctl stop pg_hardstorage` left the slot held and PG still
blocked) and the three migration guides, each of which promised a
replication slot and then enabled the agent. Three runbooks also named
`pg_hardstorage-agent`, a unit no package ever shipped.

New tests bind the units to the CLI: every unit must be in every
packaging recipe, every ExecStart must name a real verb, and some unit
must run `wal stream`.

Also merges #57-#60. #57 matters: grpc 1.83.1, merged four days ago in
#55 to clear an unreachable advisory, carried a REACHABLE one
(GO-2026-6443). 1.83.2 clears it; the binary scans clean again.

Closes #56

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RmkgG1CUNYTkZES1M4BkkN
@postgresql007

Copy link
Copy Markdown
Contributor Author

Superseded by #63.

Every commit on this branch is contained in integration/v1.5.0 — the issue #56 systemd work and the four Dependabot merges (#57-#60) — so nothing here is lost. #63 additionally carries the LLM-helper fixes that were in #62, plus the changelog and documentation for both.

Consolidating them means one review and one release rather than three, which is why this is closing rather than merging. The branch fix/56-wal-stream-systemd-unit is left in place; delete it whenever you like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

The systemd unit file for pg_hardstorage wal stream is missing.

1 participant