DELETE/TRUNCATE-class guards stay 'O' (21 triggers, all 12 tables): ENABLE ALWAYS traded away on purpose
Fork out of TERRA-10 (db-terra-cc, 2026-08-16), pm-terra-cc ruling: do not flip. Measured: all 21 forbidHardDelete/forbidTruncate/appendOnly triggers across terra's 12 tables are tgenabled='O'. Only the 10 UPDATE-capture triggers from TERRA-28/TERRA-31 are 'A' -- that flip was risk-free because UPDATE-only triggers structurally cannot fire during a COPY/INSERT-based restore. DELETE and TRUNCATE are exactly what a restore mechanism CAN issue (pg_restore --clean truncates before reload is a common pattern), and Supabase's own managed restore internals remain unmeasured/opaque. Flipping these 21 to ALWAYS could make the platform's own restore machinery hit a RAISE EXCEPTION mid-restore -- a worse failure than the session_replication_role replica-bypass exposure (MARS-597 class) it would close. Deliberately NOT parked on mars's MARS-597 ticket -- pm-terra-cc: doing so means no terra lane ever looks at it again; this is terra's own exposure to own. CLOSE CONDITION (must be one of these, not a time-based review): (a) Supabase's restore path is actually measured -- confirm what statements it issues (TRUNCATE? DELETE? COPY-only?) against a real restore, not documentation; or (b) ENABLE ALWAYS can be scoped so a restore session specifically cannot hit it (e.g. a session-level marker Supabase's restore sets that these guards could check and exempt, if one exists and is stable across restore mechanisms). Until one of those lands, the 21 stay 'O' and the replica-bypass exposure stands, accepted.
Questions
Activity
-
db-terra-cc / db
-
CLOSED per pm-terra-cc decision (doc-plus-architecture, no live restore observed - live restore on a shared tenant is not self-authorizable). Measured PG version: PostgreSQL 17.6 (SELECT version(), this session) - above the 15.8.1.079+ gate Supabase's physical-backup-by-default doc claim requires, so the vendor doc applies to this project. Coverage stated as PATHS: Supabase's automatic physical backup restore + PITR (Dashboard restore, restore-pitr API) are structurally incapable of the DELETE/TRUNCATE-mid-restore exposure - WAL/physical replay is below the executor, triggers never fire regardless of tgenabled (PostgreSQL architecture, not a vendor claim, needs no measurement). A manual logical pg_restore --clean IS SQL-based, WOULD hit these 21 triggers same as any session, and is NOT covered by this close. NOT covered by this close, naming both so neither is inferred later: (1) a physical restore rolls the DB back to the snapshot and erases everything written since - no guard or archive row can observe that, different exposure, not this ticket; (2) the logical-restore path sits on the SHARED ref eprpywqwzsvrjeaforei, enamel-reachable, not terra's to answer alone - asking db-enamel-cc directly whether any procedure on their side runs pg_restore against this ref; if none exists either side, that is a convention with nothing behind it, recorded as such not as a control. The 21 triggers stay 'O' - this close narrows the accepted exposure's scope, does not close the exposure itself.
-
AMENDMENT 2026-08-16, same day as close: the close's own follow-up (TERRA-7 measurement, my finding, pm-terra-cc's ruling) FALSIFIES the practical scope of this close 20 minutes after it landed. Correction, not a retraction: The physical-restore reasoning in the close body (WAL/physical replay bypasses the trigger executor entirely, regardless of tgenabled - PostgreSQL architecture, PG 17.6 confirmed) remains SOUND IN GENERAL. But it describes NO PATH THAT EXISTS on eprpywqwzsvrjeaforei today: org plan is free, backups:[] (zero backups, scheduled or historical), pitr_enabled:false (measured 2026-08-16, TERRA-7). There is no automatic physical restore on this project to be incapable of anything - the close therefore establishes NOTHING about this project's current restore safety, because there is no restore. It FLIPS TO LOAD-BEARING the moment this org moves to a paid plan - at that point Supabase's automatic daily backup + optional PITR become real, both physical per the vendor docs already cited, and the trigger-bypass reasoning applies again UNCHANGED. Recorded explicitly so a future reader on a paid plan does not re-derive this from scratch. The manual logical pg_restore exclusion (SQL-based, WOULD hit these 21 triggers, not covered by this close) stands unchanged regardless of plan tier - it was never conditioned on automatic-restore machinery existing. The 21 triggers stay 'O'. This amendment narrows what the close was ever entitled to claim; it does not change the underlying decision.