OpenSSLは暗号通信プロトコル「SSL/TLS」をサポートするオープンソースライブラリであり、世界全体で広く使われています。ところが、そんなOpenSSLの方向性には重大な問題があると、暗号処理用Pythonライブラリ「pyca/cryptography」の開発者兼メンテナであるポール・ケーラー氏らが指摘しました。
◆今後の方向性
ケーラー氏らは「OpenSSLに関する私たちの経験はここ数年にわたり悪化の一途を辿っています」と述べ、今後の新機能ではOpenSSLではなくLibreSSLやBoringSSL、AWS-LCでのみ利用可能な新しいAPIを追加することを発表。また、長期的にはOpenSSL以外の暗号化ライブラリへの切り替えを見据えて、潜在的な代替手段を検討していくとのことです。
最後にケーラー氏らは、「暗号実装の提供に使用するライブラリの変更が、ユーザーに重大な影響を与えることを認識しています。これらの措置を軽率に検討しているわけではなく、急いで実施するつもりもありません。しかしながら、懸念事項の重大性から行動せざるを得ないのです」と述べました。
⇧ 結構、絶望的な状況になりつつあるっぽいですな...
「リファクタリング」するにも「設計」が重要ということですかね...
PostgreSQLの拡張機能TimescaleDBの機能のData retentionが紛らわしい...
公式の「ドキュメント」によりますと、
Data retention
Data retention helps you save on storage costs by deleting old data. You can combine data retention with continuous aggregates to downsample your data.
https://www.tigerdata.com/docs/use-timescale/latest/data-retention
⇧ とあるように「Data retention」は、「古くなったデータを削除する機能」ということらしい。
具体的には、
About data retention
In modern applications, data grows exponentially. As data gets older, it often becomes less useful in day-to-day operations. However, you still need it for analysis. TimescaleDB elegantly solves this problem with automated data retention policies.
https://www.tigerdata.com/docs/use-timescale/latest/data-retention/about-data-retention
Data retention policies delete raw old data for you on a schedule that you define. By combining retention policies with continuous aggregates, you can downsample your data and keep useful summaries of it instead. This lets you analyze historical data - while also saving on storage.
https://www.tigerdata.com/docs/use-timescale/latest/data-retention/about-data-retention
⇧ 上記にありますように、自分で「データ」を削除するタイミングを「スケジュール」する「Data retention policy」を定義することが可能なのだそうだ。
で、
Create a data retention policy
Automatically drop data once its time value ages past a certain interval. When you create a data retention policy, TimescaleDB automatically schedules a background job to drop old chunks.
https://www.tigerdata.com/docs/use-timescale/latest/data-retention/create-a-retention-policy
⇧ 上記にある通り、「更新系」の「SQL」の「クエリ」なのに、「SELECT」を利用しているというね...
「PostgreSQL」って、「シーケンス」をインクリメントする時も「SELECT」を利用していたりと罠が多過ぎるんよな...
本当に、「SELECT」は「参照系」の「SQL」の「クエリ」だけで利用するようにして欲しいよね...
一応、
⇧ 上記で「引数」は説明してくれてはおりますが。
ちなみに、「Data retention policy」の削除について、
⇧ 上記のような形ということは、1つの「hypertable」、または、「continuous aggregate」は、1つの「Data retention policy」しか割り当てできないということっぽい。
まぁ、「add_retention_policy」の「引数」には「if_not_exists」があり、「remove_retention_policy」の「引数」には「if_exists」があるので、
hypertable: Data retention policy = 1: 1
continuous aggregate: Data retention policy = 1: 1
という関係になるっぽい。
そして、肝心の作成済みの「Data retention policy」を確認する方法なのだが、
■See scheduled data retention jobs
To see your scheduled data retention jobs and their job statistics, query the
timescaledb_information.jobsandtimescaledb_information.job_statstables. For example:
SELECT j.hypertable_name,
j.job_id,
config,
schedule_interval,
job_status,
last_run_status,
last_run_started_at,
js.next_start,
total_runs,
total_successes,
total_failures
FROM timescaledb_information.jobs j
JOIN timescaledb_information.job_stats js
ON j.job_id = js.job_id
WHERE j.proc_name = 'policy_retention';
■The results look like this:
-[ RECORD 1 ]-------+-----------------------------------------------
hypertable_name | conditions
job_id | 1000
config | {"drop_after": "5 years", "hypertable_id": 14}
schedule_interval | 1 day
job_status | Scheduled
last_run_status | Success
last_run_started_at | 2022-05-19 16:15:11.200109+00
next_start | 2022-05-20 16:15:11.243531+00
total_runs | 1
total_successes | 1
total_failures | 0
⇧ とあり、「timescaledb_information.jobs」という「テーブル」の「列（カラム）」の「config」で確認していそう。
「stackoverflow」でも、
⇧ とあり、「timescaledb_information.jobs」という「テーブル」から取得できると言っている。
ただ、
⇧ 公式の「ドキュメント」によりますと、
『Configuration passed to the function specified by proc_name at execution time』
とあり、「add_retention_policy」で生成された「Data retention policy」が「config」に保存されるのかが定かではない...
とは言え、生成済みの「Data retention policy」の「情報」を確認していそうな「ドキュメント」が他に見当たらないのよな...
ネットの情報を漁っていたところ、
⇧ 実際に試してみた的な投稿記事で、「add_retention_policy」で生成された「Data retention policy」が、「timescaledb_information.jobs」という「テーブル」から取得された「情報」の内の「列（カラム）」が「config」の値で確認できると言っている。
と言うか、
⇧ 上記にある通り、「Continuous aggregates」というものが作られている場合もあるそうな。
そもそも、
- Hypertables
- Hypercore
- Continuous aggregates
の関係がサッパリ分からない...
公式のブログ記事によると、
⇧ 上記では、3種類の「policy」が存在するようなのだが...
「Google Gemini」に質問してみたところ、以下のような回答が返ってきた。
■TimescaleDB：機能とポリシーの対応まとめ
| 機能 (コンポーネント) | 関連するポリシー | 主な目的 | 実行・自動化のタイミング |
|---|---|---|---|
| Hypertable | Retention Policy |
【土台】 自動パーティショニングとデータ保持期間の管理 |
データ挿入は常時。削除はポリシー設定（例：30日経過後）に基づき実行。 |
| Hypercore | Compression Policy |
【圧縮】 行形式から列形式への変換によるストレージ削減 |
設定した期間（例：7日経過後）に、バックグラウンドで一括圧縮。 |
| Continuous Aggregate | Refresh Policy |
【集計】 マテリアライズド・ビューの増分更新と最新化 |
スケジュール設定（例：1時間ごと）に従い、新着分を自動集計。 |
う～む...、「Retention policy」は「Continuous Aggregate」にも割り当て可能なはずなので、「回答」が「幻覚（ハルシネーション）」を引き起こしていそうよね...
「生成AI」は「情報」の「分類」、「整理」に難ありなのかね？
いつまで経っても「ファクトチェック」の負担が減らないではないか...
一次情報が役に立たない状況は何とかして欲しい...
兎にも角にも、
計算機科学において、Garbage In, Garbage Out（ガービッジ・イン、ガービッジ・アウト／ガベージ・イン、ガベージ・アウト）、略してGIGOとは、欠陥のある、または無意味な（garbage）入力データは無意味な出力を生み出すという概念である。直訳は「ゴミを入力するとゴミが出力される」。すなわち、「『無意味なデータ』をコンピュータに入力すると『無意味な結果』が返される」という意味である。Rubbish in, rubbish out (RIRO)とも表現される
⇧ 上記にある通り、「インプット（入力）」が宜しくないと「アウトプット（結果）」が良くなりようが無いのよ...
2026年1月16日（金）19:00 追記：↓ ここから
何やら、
⇧ 上記にある通り、
- _timescaledb_catalog
- _timescaledb_functions
- _timescaledb_internal
- _timescaledb_cache
- timescaledb_experimental
- timescaledb_information
の6つの「スキーマ」が生成されるのだが、公式の「ドキュメント」でこれらの「情報」についてを説明して欲しいところですな...
いやはや、「ブラックボックス」ですな。
2026年1月16日（金）19:00 追記：↑ ここまで
毎度モヤモヤ感が半端ない…
今回はこのへんで。
