PostgreSQL 18 cancel request key長の変更とRailsへの関連

1. 第53回 PostgreSQLアンカンファレンス@オンライン Yasuo Honda @yahonda PostgreSQL 18 cancel request key長の 変更とRailsへの関連
2. • Yasuo Honda @yahonda ◦ Rails committer ◦ 6回目の参加です ▪ PostgreSQL 15とRailsと - Speaker Deck ▪ 遅延可能な一意性制約 - Speaker Deck ▪ pg_stat_statementsで inの数が違うSQLをまとめて ほしい - Speaker Deck ▪ NOT VALIDな検査制約 / check constraint that is not valid - Speaker Deck ▪ extensionとschema - Speaker Deck 自己紹介
3. 前置き
4. • Active Record利用してリレーショナルデータベースを利用 ◦ 標準で対応するデータベース ◦ SQLite ◦ MySQL ◦ PostgreSQL (現在のmainブランチはバージョン9.3以上に対応) • pg gem https://github.com/ged/ruby-pg に依存 ◦ PostgreSQLへのRubyインターフェース ◦ libpqを利用 PostgreSQL とRuby on Rails
5. • Virtual generated columns / 仮想生成列 ◦ https://github.com/rails/rails/pull/55142 ◦ PostgreSQL 12のStored generated columns (格納生成列) ▪ Rails 7.0で対応済み(2021年12月リリース) ▪ https://github.com/rails/rails/pull/41856 ◦ https://www.postgresql.jp/docs/17/ddl-generated-column s.html • https://www.postgresql.org/message-id/flat/CAK_s-G2Q7de8 Q0qOYUR%3D_CTB5FzzVBm5iZjOp%2BmeVWpMpmfO0w%40 mail.gmail.com という議論継続中 PostgreSQL 18の新機能対応 1
6. • Remove support for unlogged on partitioned tables ◦ https://git.postgresql.org/gitweb/?p=postgresql.git;a=com mitdiff;h=e2bab2d79 • https://github.com/rails/rails/pull/47499 ◦ Unit testの高速化のためにテスト内で作成されるテーブルを UNLOGGEDにしていた • https://github.com/rails/rails/pull/53439 ◦ テスト内でのパーティション表をUNLOGGEDにしないようにするpull request PostgreSQL 18の新機能対応 2
7. 本題
8. • Make cancel request keys longer ◦ https://github.com/postgres/postgres/commit/a460251f0a 1ac987f0225203ff9593704da0b1a9 ◦ “The longer cancellation keys are generated when using the new protocol version 3.2. For connections using version 3.0, short 4-bytes keys are still used.” • Protocol version 3.2 はPostgreSQL 18から ◦ https://www.postgresql.org/about/news/postgresql-18-be ta-1-released-3070/ ◦ https://github.com/postgres/postgres/commit/285613c60 a7a PostgreSQL 18の新機能対応 3
9. • pg gem v1.5.9でcancelを呼ぶ際のbackend_keyが取れずキャンセル できない ◦ https://github.com/ged/ruby-pg/blob/afe2f208f7d5eacea1 260ce1def10e1fb30b8241/lib/pg/connection.rb#L599 ◦ https://github.com/ged/ruby-pg/blob/afe2f208f7d5eacea1 260ce1def10e1fb30b8241/ext/pg_connection.c#L1022-L102 3 PostgreSQL 18の新機能対応 3
10. • pg gem master branchはPostgreSQL 17以上の場合は下記を利用 ◦ https://www.postgresql.org/docs/17/libpq-cancel.html ◦ PQcancelBlocking ◦ PQcancelStart ◦ PQcancelPoll ◦ https://github.com/postgres/postgres/commit/61461a300c 1cb5d53955ecd792ad0ce75a104736 • 16以下の場合は従来のbackend_key取得方法にする ◦ https://github.com/ged/ruby-pg/pull/614 PostgreSQL 18の新機能対応 3 (cont)
11. • RailsがサポートするPostgreSQLバージョンを10以上にする提案 ◦ https://discuss.rubyonrails.org/t/proposal-bump-the-mini mum-supported-postgresql-version-from-9-3-to-10/8942 2/1 • pg gem 1.6.0 ◦ PostgreSQL 18でcancel可能なバージョン ◦ pg gemがサポートするPostgreSQLバージョンが10以上になるため • データベースそのもののEOLとは別の考え方 PostgreSQL 18の新機能対応 3 (cont)
12. 発表後に教えてもらったことと 調べたこと
13. • PgBouncer の振る舞いによるものとのこと ◦ “So instead of bumping to 3.1, we’re bumping the protocol version to 3.2. This ensures that affected PgBouncer versions correctly close the connection during the startup packet phase. Skipping a version number due to a bug in a third-party application may seem unusual, but given PgBouncer’s widespread use, it’s a practical choice to avoid confusion for users connecting through recent versions. Since skipping a minor protocol version has no real cost, this decision—while not the most theoretically pure—is the most pragmatic. • https://www.postgresql.org/message-id/flat/CAGECzQQisJgO hP2ETokQtsW-rNui-z2rMXbq5RUGNfDcYz6kxg%40mail.gmail.c om#7827b13f40b2ea1470c26bf7b2db31b2 • https://github.com/pgbouncer/pgbouncer/pull/1007 なぜProtocol 3.0の次が3.1を飛ばして 3.2なのか
14. おわり