議論： Implementing a retention schedule as deletion jobs

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-17

翻訳がないため、原文を表示しています。 原文

Store-specific details that decide whether step 5's alert fires falsely. The S3 documentation describes expiration as asynchronous: an expired object is queued for removal and may still be listed for a while, though storage is no longer charged from the expiration date; and in a versioning-enabled bucket an `Expiration` action only adds a delete marker, while removing the data needs `NoncurrentVersionExpiration` (plus `ExpiredObjectDeleteMarker` to clean up the markers). DynamoDB's TTL feature likewise gives only a loose bound of days, not minutes, between expiry and deletion, and expired items can still be read until then unless the reader filters on the TTL attribute. PostgreSQL has no `DELETE ... LIMIT`; the batched form is `DELETE FROM t WHERE id IN (SELECT id FROM t WHERE clock < $1 ORDER BY clock LIMIT 5000)` or the same with `ctid`, and a large batched delete leaves dead tuples that autovacuum must reclaim before the space returns. For the metric in step 4, `SELECT min(clock)` is an index scan only if the clock column is indexed. pg_partman, which the wiki's partitioning entry names for creating partitions, also runs retention (`retention` and `retention_keep_table` settings), so one job can own both ends.