docker: ship postgresql-client for the bootstrap-index recipes#110
Merged
Conversation
In a multi-recipe invocation (just a b c) a recipe with a positional param eats the next recipe name as its argument — 'just compact-all-tiers expire ...' compacts table="expire". The composition-stamped tenant maintenance CronJob runs one flat chain (bootstrap-indexes compact-all-tiers-default expire-7d purge-orphan-stats cleanup-all), so the two parameterized steps get no-arg wrappers with the fleet defaults pinned. The step SEQUENCE deliberately lives in the cron definition (crossplane composition), not an umbrella recipe here — changing steps must not require a millpond release.
The justfile's bootstrap-index-* recipes shell out to psql for CREATE INDEX CONCURRENTLY (cannot run inside a transaction, so the python/duckdb connection path is not a substitute). The runtime image never carried psql — the central viaduck crons never ran these recipes, so it went unnoticed until the composition-stamped tenant maintenance cron put bootstrap-indexes first in its chain: every run dies at 'psql: not found' before any compaction happens.
jghoman
added a commit
that referenced
this pull request
Jul 24, 2026
CREATE SECRET (TYPE s3, PROVIDER credential_chain) — the Pod-Identity path the composition-stamped tenant maintenance crons use — requires the aws extension. It was never pre-installed, so DuckDB attempted a runtime auto-install, which dies on the crons' read-only root filesystem: Cannot open file ".../.duckdb/extensions/v1.5.2/linux_arm64/ aws.duckdb_extension.tmp-...": Read-only file system The central viaduck crons never hit this: they authenticate with static env credentials, which need no aws extension. Same first-time-exercised class as the psql gap (#110): observed live on the first tenant cron run that got past bootstrap-indexes.
jghoman
added a commit
that referenced
this pull request
Jul 24, 2026
CREATE SECRET (TYPE s3, PROVIDER credential_chain) — the Pod-Identity path the composition-stamped tenant maintenance crons use — requires the aws extension. It was never pre-installed, so DuckDB attempted a runtime auto-install, which dies on the crons' read-only root filesystem: Cannot open file ".../.duckdb/extensions/v1.5.2/linux_arm64/ aws.duckdb_extension.tmp-...": Read-only file system The central viaduck crons never hit this: they authenticate with static env credentials, which need no aws extension. Same first-time-exercised class as the psql gap (#110): observed live on the first tenant cron run that got past bootstrap-indexes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The justfile's
bootstrap-index-*recipes shell out topsqlforCREATE INDEX CONCURRENTLY(can't run inside a transaction, so the python/duckdb connection path is not a substitute). The runtime image never carried psql — the central viaduck crons never ran these recipes, so it went unnoticed until the composition-stamped tenant maintenance cron (charts #13458) putbootstrap-indexesfirst in its chain: every run dies atpsql: not found(exit 127) before any compaction happens. Observed live on team-2's first*/15run.After merge this needs a release + the charts
compactionImage.tagbump to unblock the tenant crons.