29 lines
1.5 KiB
SQL
29 lines
1.5 KiB
SQL
|
-- Release the blob reference when an attachment row goes away.
|
||
|
|
--
|
||
|
|
-- `storage.file_attached_blobs.file_id` is `ON DELETE CASCADE`, so deleting a
|
||
|
|
-- file removes its attachment rows inside the database — invisible to Rust.
|
||
|
|
-- The lifecycle hook cannot cover this: `on_file_deleted` fires AFTER
|
||
|
|
-- `delete_file`, by which point the cascade has already run and there is
|
||
|
|
-- nothing left to read. The references would survive with no row behind them,
|
||
|
|
-- and `dedup_gc` would see a positive count forever — bytes pinned for good.
|
||
|
|
--
|
||
|
|
-- `storage.decrement_blob_ref()` already exists for exactly this, on
|
||
|
|
-- `storage.files`. It keys off `OLD.blob_hash` and is otherwise
|
||
|
|
-- table-agnostic, so it applies verbatim — and reusing it keeps the
|
||
|
|
-- manifest-first decrement contract defined in one place rather than
|
||
|
|
-- transcribed into a second trigger that can drift.
|
||
|
|
--
|
||
|
|
-- Only DELETE. Replacing a preview updates `blob_hash` in place
|
||
|
|
-- (`store_attached_blob` is ON CONFLICT DO UPDATE), and the reference to the
|
||
|
|
-- superseded blob is released there, in Rust. Adding UPDATE here would
|
||
|
|
-- double-decrement it.
|
||
|
|
|
||
|
|
CREATE OR REPLACE TRIGGER trg_file_attached_blobs_decrement_blob_ref
|
||
|
|
AFTER DELETE ON storage.file_attached_blobs
|
||
|
|
FOR EACH ROW
|
||
|
|
EXECUTE FUNCTION storage.decrement_blob_ref();
|
||
|
|
|
||
|
|
COMMENT ON TRIGGER trg_file_attached_blobs_decrement_blob_ref
|
||
|
|
ON storage.file_attached_blobs IS
|
||
|
|
'Releases the blob reference held by an attachment row. Needed because file_id is ON DELETE CASCADE, so rows vanish inside the DB where the Rust lifecycle hooks cannot see them.';
|