Skip to content

feat(cmd/duckgres-worker): add a worker-only entry point that ships libduckdb#500

Merged
fuziontech merged 1 commit intomainfrom
feature/cmd-worker-binary
May 1, 2026
Merged

feat(cmd/duckgres-worker): add a worker-only entry point that ships libduckdb#500
fuziontech merged 1 commit intomainfrom
feature/cmd-worker-binary

Conversation

@fuziontech
Copy link
Copy Markdown
Member

Summary

Counterpart to cmd/duckgres-controlplane (PR #498). This binary:

  • Links libduckdb (verified: go list -deps shows duckdb-go-bindings, duckdb-go/v2 in the import graph).
  • Imports duckdbservice but not controlplane — no PG wire surface, no config-store / k8s pool wiring. It's the runtime that the control plane spawns into worker pods over Unix sockets / TCP.
  • Is the target of the planned per-DuckDB-version matrix build in CI. A worker pod ships exactly one DuckDB version, pinned via go.mod + the Dockerfile DUCKDB_EXTENSION_VERSION build arg.

Like cmd/duckgres-controlplane, this is a stub that errors out at runtime — duckgres' YAML / CLI / env config resolution still lives in the package main file at the repo root alongside the all-in-one binary. The follow-up PR lifts that into a shared package both new binaries can import. The point of this PR is locking in the binary's existence and the import-graph contract.

Where the binary split now stands

Together with PR #498 (CP-only, no libduckdb) and PR #499 (CI guard), the binary split is structurally complete:

Binary libduckdb Modes
cmd/duckgres-controlplane no control-plane only (all DuckDB versions run on remote workers)
cmd/duckgres-worker yes duckdb-service only (pinned to one DuckDB version per build)
duckgres (all-in-one) yes all modes (standalone / control-plane / duckdb-service)

Test plan

🤖 Generated with Claude Code

…ibduckdb

Counterpart to cmd/duckgres-controlplane (PR #498). This binary:

  - Links libduckdb (verified: go list -deps shows duckdb-go-bindings,
    duckdb-go/v2 in the import graph).
  - Imports duckdbservice but not controlplane — no PG wire surface, no
    config-store / k8s pool wiring. It's the runtime that the control
    plane spawns into worker pods over Unix sockets / TCP.
  - Is the target of the planned per-DuckDB-version matrix build in CI.
    A worker pod ships exactly one DuckDB version, pinned via go.mod +
    the Dockerfile DUCKDB_EXTENSION_VERSION build arg.

Like cmd/duckgres-controlplane, this is a stub that errors out at
runtime — duckgres' YAML / CLI / env config resolution still lives in
the package main file at the repo root alongside the all-in-one binary.
The follow-up PR lifts that into a shared package both new binaries
can import. The point of this PR is locking in the binary's existence
and the import-graph contract.

Together with PR #498 (CP-only, no libduckdb) and PR #499 (CI guard),
the binary split is now structurally complete:

  cmd/duckgres-controlplane   no libduckdb (CP-only, all DuckDB versions
                              run on remote workers)
  cmd/duckgres-worker         links libduckdb (worker-only, pinned to
                              one DuckDB version per build)
  duckgres                    all-in-one (links libduckdb, all modes)

Verified:
  - go build ./cmd/duckgres-worker/... clean
  - go list -deps ./cmd/duckgres-worker | grep duckdb-go shows the
    expected DuckDB driver imports
  - go list -deps ./cmd/duckgres-controlplane | grep duckdb-go is still
    empty (the CP-only contract held)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@fuziontech fuziontech enabled auto-merge (squash) May 1, 2026 18:18
@fuziontech fuziontech merged commit 14a4e2e into main May 1, 2026
21 of 22 checks passed
@fuziontech fuziontech deleted the feature/cmd-worker-binary branch May 1, 2026 18:21
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.

1 participant