feat(datastore): add subject_digest column to manifests

What

Adds a nullable subject_digest bytea column to the manifests table (pre-deploy migration), and regenerates structure.sql.

This is step 1 of #2376. The column is not yet read or written by any code; it is the foundation for making the OCI subject relationship correct when a referrer is pushed before its subject (the scenario tolerated by !2927 (merged)).

Why

subject_id is resolved only at push time. When a referrer is pushed before its subject, it is stored with subject_id = NULL and never repaired, which breaks referrer discovery and online GC's subject protection (see #2376 for the full analysis and diagram). subject_digest records the declared subject digest on every push regardless of whether the subject exists, so a later step can backfill subject_id when the subject arrives.

Follow-ups (separate MRs)

  1. Datastore plumbing: thread subject_digest through models.Manifest, the manifest INSERTs, the row scanners, and the manifest SELECT column lists.
  2. Composite index on (top_level_namespace_id, repository_id, subject_digest) (likely partial WHERE subject_id IS NULL), using the batched per-partition CREATE INDEX CONCURRENTLY pattern (mirroring the subject_id index rollout) — DBRE input on the rollout.
  3. Write path: set subject_digest on push and backfill subject_id when the subject is created (trigger-based, atomic with the insert).

Testing / verification

  • ALTER TABLE manifests ADD COLUMN IF NOT EXISTS subject_digest bytea applied cleanly via registry database migrate up against Postgres 17 (194 pre + 20 post migrations).
  • structure.sql regenerated with pg_dump 17 and pgFormatter 5.0; the diff is exactly the new column on the manifests parent and all 64 partitions, with no reformatting noise.
  • go build ./... passes.

Part of #2376. Follows !2927 (merged).

Merge request reports

Loading
Loading