第53回 PostgreSQLアンカンファレンス@オンライン Yasuo Honda @yahonda PostgreSQL 18 cancel request key長の 変更とRailsへの関連 

● 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 自己紹介 

前置き 

● Active Record利用してリレーショナルデータベースを利用 ○ 標準で対応するデータベース ○ SQLite ○ MySQL ○ PostgreSQL (現在のmainブランチはバージョン9.3以上に対応) ● pg gem https://github.com/ged/ruby-pg に依存 ○ PostgreSQLへのRubyインターフェース ○ libpqを利用 PostgreSQL とRuby on Rails 

● 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 

● 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 

本題 

● 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 

● 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 

● 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) 

● 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) 

発表後に教えてもらったことと 調べたこと 

● 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なのか 

おわり