5.2 KiB
PostgreSQL group journal source candidate
Prepared against NetKingdom 6cb43c0cc55212363a5406b02db046e2384a7c40 for
NK-WP-0048-T14. No canonical change, native database/credential access, package
installation, Docker call or production admission occurred in preparation.
source.patch, exact postimages and source-manifest.json bind the source.
The existing reserve/get/claim-revoke/save/check seam is now explicit as
GroupJournalStore. The new injection-only PostgreSQL implementation preserves
prestate, intents, confirmed creation inventories and active fences using the
same provisioner paths. SQL updates require the exact context/key/request and
receipt version, plus exactly one affected row; the journal head and exact
transition digest also advance conditionally under a metadata-row lock. Each
new digest binds the prior marker and canonical body/context/key/version. An
independent checkpoint compares and CAS-advances both sequence and content,
refusing a divergent clone even if it reaches the same counter. SQL errors, stale CAS and ambiguous
commit/checkpoint acknowledgment refuse rather than permitting the next LDAP
effect. No exception handler can automatically turn those failures into success.
A frozen explicit tenant/directory/case/source/principal/epoch binding is required; there is no request-derived authority or default platform-root scope. The owner must additionally supply independent durable continuity checkpoint callbacks and renewable connection facts. These are injection seams, not new authorization or evidence services, and no native implementation or grant is invented. The ordinary server has no Pg environment switch: missing native callbacks keep the production Pg group path disabled. The existing SQLite path remains local/test only under accepted ADR-0015.
The migration creates tables inside the existing consumer schema. It performs no provisioning, initializes no epoch and admits/clears no quarantine. A journal restored behind the separately retained checkpoint is refused. Admission must still bind native restore/continuity, record retention, owner scope and runtime credentials; an injected callback that merely asserts success proves none of those boundaries. SQL locking fences only cooperating journal callers and does not close LLDAP external-writer/ABA races.
The Containerfile includes the module/migration and hash-pinned psycopg3 closure selected from User Engine's existing lockfile (Linux amd64 CPython3.12 only). No image was built and no package was fetched. Immutable rebuild, dependency scanning, platform/cell/consumer acceptance and native storage/backup/lease/TLS proof remain owner work. The native fixture uses the exact cached User Engine image's bundled psycopg version and records it; this is compatibility proof, not verification of a future rebuilt image.
Source checks cover explicit binding/no default, disabled server routing, stale
checkpoint/quarantine/epoch refusal, exact row CAS, commit-before-checkpoint
ordering, missing acknowledgment, cross-context/version import refusal,
active-fence/capacity and connection failure sanitization. Scripted DB-API unit
checks do not prove PostgreSQL semantics. The separately review-gated
native-fixture uses real disposable PostgreSQL SQL and the existing synthetic
LDAP Directory, with actual separate-process reopen and pg_dump/pg_restore.
No PostgreSQL fixture execution or native acceptance is counted yet.
The counter-only predecessor and coordinator finding remain under review-r0;
it is superseded and never admitted or executed. The successor adds content-bound
continuity rather than accepting a same-counter result.
The source deliverable does not finish T14: runtime package/operating assignment, CNPG/rapp-postgres consumer/capacity and lease/custody approval, independently retained native checkpoints, accepted case/source/principal and protected session/evidence callbacks, LDAP writer fencing/CAS and production rollout all remain open. Existing native-storage-proposal-r1 records those owner routes.
R4 native failure refinement
R3 reached bootstrap_ensure then failed safely with RuntimeError and no SQLSTATE;
initdb/readiness/migration/runtime grants and checkpoint initialization completed.
Its exact internal exception text was never collected. Frozen fixture/receipt and
source503e3 remain in native-fixture/revisions/r3 and review-r3.
Local diagnosis demonstrated a PostgreSQL save contract defect: save replaced the
nested receipt dictionaries while the real provisioner retained a group-state
reference across its intent save. The returned created ID therefore updated a
detached object; final receipt postimage checking refused. R4 updates only the
acknowledged _pg_version after successful commit and independent checkpoint;
it retains nested caller references, with no change to SQL/CAS, digest, ownership
or ambiguous-commit behavior. A regression fails against frozen source, and a
second runs the actual synthetic Directory/provisioner with actual PostgreSQL
save/write/transaction code and mocked SQL transport to verify complete ensure.
82 source tests pass. Actual native compatibility remains unproved until reviewed
R4 execution; this fix does not imply production or tenant admission.