スピンロックって何かと思ったらビジーウェイトのこと？ PostgreSQL はそんなことしてたのか。普通にやったらあかんやつだと思うんだが。
UbuntuはリリースされたばかりのカーネルをLTSに組み込むのか―。理由が明確ならポスグレ側の対応が終わるまでアップグレードを控えそうなもの。
https://x.com/kosaki55tea/status/2040458791536497035
カーネル開発者の「アプリ側で直せ」は様式美だけど、1.9xの性能差は笑えないな。Ubuntu 26.04がこれ積むなら阿鼻叫喚になりそう
昔からダメだって言われてたやつ。Postgre側があかん。
代替まで用意されてて変わる直前にグダついてるなんてダサすぎる いくらpostgresといえどこういうのに手心加えるべきじゃない
PostgreSQLに限らず、普通に考えたら「アプリが動かないからOS側が歩み寄れ」って指摘はOSのバグでない限り対応しなさそう。これはPostgreSQL側が対応しないといかんのちゃう？
あーこれ私直接的に影響受けそうだなー
PostgresSQLのほうが上位レイヤーだから上位レイヤーの修正すべき案件だよな
do not use spinlocks in user space, unless you actually know what you're doing https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723
PostgreSQLは、政治力低そうだしなあ。ubuntuの最新LTSにはもうLinux7.0はいってくるのね
postgresql+ubuntu ltsを使っている人には深刻だな・・・
PostgreSQL以外のRDBMSには関係ない話なん？（↓の感じだとPostgreSQLだけが変なことしてるっぽい？）
一方WindowsはSimCity2000の挙動が変わることの影響が大きすぎてOSのバグを修正できなかった
うーん、PostgreSQL を使うなら FreeBSD で運用してたほうがいいのかな。とはいえ環境や扱うデータによっては高速化してるパターンもあるのか
Linux哲学は互換性重視じゃなかったのか
「AWSのGraviton4のような大規模インスタンスはまさにPostgreSQLの主戦場」と書いてあるが、gravitonはarmだけどこの問題が発生する？
kernel側がアプリケーションのためにこのあたりを戻すことはないと思うし、こういう問題をみつけるためのrc。
Amazon Redshiftが影響受けそう
MySQLのドキュメントにスピンロックのポーリングの記載があるけど、MySQLは無関係なのかな？スレッドベース（mutex/rw-lock）だから問題なし？ https://dev.mysql.com/doc/refman/8.0/ja/innodb-performance-spin_lock_polling.html
ポスグレが無くなったらlinuxを選択肢から除外する奴って相当増えるんじゃないのか。
ちょっと待って！！プレイバック！！！
ていうかこのサイトなに？ FireFoxだと少しUIが崩れてるもののトップページには興味深い記事が結構あるし面白い。AIかなにかにHacker news巡回させてるの？
スピンロック！！！！！！組み込みやん！！！！！！！
"技術的には筋が通っている" "現実的な問題" / 「筋の通ってない側が困る」 だけの話を、数を理由に「現実的な問題」と言い換えるの、まさに政治的な手法で、技術屋がやられたら一番腹立つことを自分の時はやるんだねｗ
プラットフォーム側の規約変更で翻弄されるYouTuberみたいなもんか。
ポスグレなんて使ってるやつが悪いわ
MySQLはもうちょっとお行儀がいいということなのかな https://zenn.dev/awache/articles/7018d266b76e8c
トップブコメ見ると10年以上前からポスグレ側で問題を認識してるんだから今までの期間でなんとかしろよとかしか思えないな
PostgresがフォークしてOSを提供しなさいよ、とは思うが。どうせDBなんてほぼ閉鎖環境なんだよね？
「Linux 7.0の開発カーネル上で、PostgreSQLのスループットが従来の約半分にまで落ち込んでいる」「PostgreSQL側のコード変更が必要になる」/最近分かった話なのかと思ったら↓20年くらい前から言われていたらしい。
カーネル開発者の回答──「PostgreSQLが変わるべき」> 筋論としては正しくその通り。
夜間バッチなんかはDB性能が半減したら、普通に朝になっても終わらないっていう激重の障害になるだろうな。対策前のPostgreSQLとLinux7以降の組み合わせを選んだらいつでも踏むわけで、話自体は覚えといたほうがよさげ
いくら deprecated な挙動を利用していたとしても移行期間を宣告しないのは不誠実に捉えてしまうが。ここにコメントしてるエンジニア諸氏は同じことをされて引き下がれるのか。
Linuxカーネルは“WE DO NOT BREAK USERSPACE!”が原則だと思ってたけど、本当にPostgreSQL側が悪いからと言って事前調整なしに修正を強行したの？ / なるほどKernel API は変更されていないのね https://x.com/kosaki55tea/status/2040561944080646463
やばー
リーナスの裁定が望まれる場面ぽい
“目的はカーネルの簡素化とPREEMPT_RT（リアルタイム対応）への統合推進だが、その副作用がPostgreSQLを直撃”、”PREEMPT_LAZYに変わったことで、ロック保持中にタスクが中断される頻度が上がり、他のプロセスが無駄にスピン
あら、AWSのRDSのカーネルバージョン調べとかないと、、、→非公開やったわ。ニュース追っとかないと急に遅くなったってなると嫌だし
PostgreSQLが行儀の悪い動作をできなくなっただけ
ブコメのリンク先にもあるけどUbuntuってPREEMPT_NONEじゃないので26.04LTSの影響ってそんなにあるのかね？実質Amazon Linux限定なのかな。/記事にある通りLinux7.0+PostgreSQLで性能向上な場合もあって実際どうなるかは条件次第か。
RDSのOSは非公開なのでPostgresが対応するまでAWSが7.0カーネルにアップグレードしない、かな
紅茶かコーヒー飲む時間に充てたら。それかタバコ
MySQLや言語ランタイムのGCもユーザ空間s_lock使ってるらしいけど、問題にならないの？→Opus：InnoDBは適応型スピンロックだし、スレッドモデルでコンテキストスイッチが軽いから平気。GCはそこまで依存してない／ほんまか
Linux 7.0でPostgreSQL性能半減、修正困難か
スピンロックって何かと思ったらビジーウェイトのこと？ PostgreSQL はそんなことしてたのか。普通にやったらあかんやつだと思うんだが。
UbuntuはリリースされたばかりのカーネルをLTSに組み込むのか―。理由が明確ならポスグレ側の対応が終わるまでアップグレードを控えそうなもの。
https://x.com/kosaki55tea/status/2040458791536497035
カーネル開発者の「アプリ側で直せ」は様式美だけど、1.9xの性能差は笑えないな。Ubuntu 26.04がこれ積むなら阿鼻叫喚になりそう
昔からダメだって言われてたやつ。Postgre側があかん。
代替まで用意されてて変わる直前にグダついてるなんてダサすぎる いくらpostgresといえどこういうのに手心加えるべきじゃない
PostgreSQLに限らず、普通に考えたら「アプリが動かないからOS側が歩み寄れ」って指摘はOSのバグでない限り対応しなさそう。これはPostgreSQL側が対応しないといかんのちゃう？
あーこれ私直接的に影響受けそうだなー
PostgresSQLのほうが上位レイヤーだから上位レイヤーの修正すべき案件だよな
do not use spinlocks in user space, unless you actually know what you're doing https://www.realworldtech.com/forum/?threadid=189711&curpostid=189723
PostgreSQLは、政治力低そうだしなあ。ubuntuの最新LTSにはもうLinux7.0はいってくるのね
postgresql+ubuntu ltsを使っている人には深刻だな・・・
PostgreSQL以外のRDBMSには関係ない話なん？（↓の感じだとPostgreSQLだけが変なことしてるっぽい？）
一方WindowsはSimCity2000の挙動が変わることの影響が大きすぎてOSのバグを修正できなかった
うーん、PostgreSQL を使うなら FreeBSD で運用してたほうがいいのかな。とはいえ環境や扱うデータによっては高速化してるパターンもあるのか
Linux哲学は互換性重視じゃなかったのか
「AWSのGraviton4のような大規模インスタンスはまさにPostgreSQLの主戦場」と書いてあるが、gravitonはarmだけどこの問題が発生する？
kernel側がアプリケーションのためにこのあたりを戻すことはないと思うし、こういう問題をみつけるためのrc。
Amazon Redshiftが影響受けそう
MySQLのドキュメントにスピンロックのポーリングの記載があるけど、MySQLは無関係なのかな？スレッドベース（mutex/rw-lock）だから問題なし？ https://dev.mysql.com/doc/refman/8.0/ja/innodb-performance-spin_lock_polling.html
ポスグレが無くなったらlinuxを選択肢から除外する奴って相当増えるんじゃないのか。
ちょっと待って！！プレイバック！！！
ていうかこのサイトなに？ FireFoxだと少しUIが崩れてるもののトップページには興味深い記事が結構あるし面白い。AIかなにかにHacker news巡回させてるの？
スピンロック！！！！！！組み込みやん！！！！！！！
"技術的には筋が通っている" "現実的な問題" / 「筋の通ってない側が困る」 だけの話を、数を理由に「現実的な問題」と言い換えるの、まさに政治的な手法で、技術屋がやられたら一番腹立つことを自分の時はやるんだねｗ
プラットフォーム側の規約変更で翻弄されるYouTuberみたいなもんか。
ポスグレなんて使ってるやつが悪いわ
MySQLはもうちょっとお行儀がいいということなのかな https://zenn.dev/awache/articles/7018d266b76e8c
トップブコメ見ると10年以上前からポスグレ側で問題を認識してるんだから今までの期間でなんとかしろよとかしか思えないな
PostgresがフォークしてOSを提供しなさいよ、とは思うが。どうせDBなんてほぼ閉鎖環境なんだよね？
「Linux 7.0の開発カーネル上で、PostgreSQLのスループットが従来の約半分にまで落ち込んでいる」「PostgreSQL側のコード変更が必要になる」/最近分かった話なのかと思ったら↓20年くらい前から言われていたらしい。
カーネル開発者の回答──「PostgreSQLが変わるべき」> 筋論としては正しくその通り。
夜間バッチなんかはDB性能が半減したら、普通に朝になっても終わらないっていう激重の障害になるだろうな。対策前のPostgreSQLとLinux7以降の組み合わせを選んだらいつでも踏むわけで、話自体は覚えといたほうがよさげ
いくら deprecated な挙動を利用していたとしても移行期間を宣告しないのは不誠実に捉えてしまうが。ここにコメントしてるエンジニア諸氏は同じことをされて引き下がれるのか。
Linuxカーネルは“WE DO NOT BREAK USERSPACE!”が原則だと思ってたけど、本当にPostgreSQL側が悪いからと言って事前調整なしに修正を強行したの？ / なるほどKernel API は変更されていないのね https://x.com/kosaki55tea/status/2040561944080646463
やばー
リーナスの裁定が望まれる場面ぽい
“目的はカーネルの簡素化とPREEMPT_RT（リアルタイム対応）への統合推進だが、その副作用がPostgreSQLを直撃”、”PREEMPT_LAZYに変わったことで、ロック保持中にタスクが中断される頻度が上がり、他のプロセスが無駄にスピン
あら、AWSのRDSのカーネルバージョン調べとかないと、、、→非公開やったわ。ニュース追っとかないと急に遅くなったってなると嫌だし
PostgreSQLが行儀の悪い動作をできなくなっただけ
ブコメのリンク先にもあるけどUbuntuってPREEMPT_NONEじゃないので26.04LTSの影響ってそんなにあるのかね？実質Amazon Linux限定なのかな。/記事にある通りLinux7.0+PostgreSQLで性能向上な場合もあって実際どうなるかは条件次第か。
RDSのOSは非公開なのでPostgresが対応するまでAWSが7.0カーネルにアップグレードしない、かな
紅茶かコーヒー飲む時間に充てたら。それかタバコ
MySQLや言語ランタイムのGCもユーザ空間s_lock使ってるらしいけど、問題にならないの？→Opus：InnoDBは適応型スピンロックだし、スレッドモデルでコンテキストスイッチが軽いから平気。GCはそこまで依存してない／ほんまか