PostgreSQL 9.6 - GUCの変更

ということでPostgreSQL 9.6 beta1が予定どおり、5/12にリリースされましたよ。
それにしても今回はalphaバージョンはなしなのか。

GUCの差分を見てみた

とりあえず、動かしてみる前に9.5と9.6のGUCの差分を確認してみた。
結構いろんなパラメータの追加や、値域の変更があるなあ。

パラメータ名 変更の種別 内容 ぬこメモ
autovacuum_max_workers 最大値の変更 8388607から262143になった。 10より大きくしたことない気がするのでわりとどうでもいい。
backend_flush_after 新規追加 ディスクフラッシュに関するパラメータ? 通常はデフォルト値(16ページ)のままでいいのかなあ?
bgwriter_flush_after 新規追加 上のパラメータのbgwriter版? これも通常はデフォルト(64ページ)のままでいいのかなあ?
checkpoint_flush_after 新規追加 上のパラメータのcheckpointer版? これも(略)(32ページ)の(略)
enable_fkey_estimates 新規追加 プランナで結合時の推定に外部キーの情報を使うか否か? 該当クエリのEXPLAINをとって確認するのが手っ取り早いかな
force_parallel_mode 新規追加 パラレルスキャンを強制? enable_* パラメータみたいなものかな?
idle_in_transaction_session_timeout 新規追加 一定時間のidle in transaction sessionを切断 運用ミスによるロングトランザクション防止に使えそう?
max_connections 最大値の変更 8388607から262143になった。 これもせいぜい1000くらいまでしか上げないからなあ・・・
max_parallel_degree 新規追加 ノード実行時に同期実行するプロセス数上限値 パラレルスキャンに関する重要なパラメータっぽい
max_prepared_transactions 最大値の変更 8388607から262143になった。 このパラメータ自体チューニングで使ったこと、あったけなあ・・・
max_replication_slots 最大値の変更 8388607から262143になった。 レプリケーションスロット数をそんな大きな値に設定したことがそもそもない。
max_wal_senders 最大値の変更 8388607から262143になった。 wal senderプロセス数って、もうちょっと上限小さくてもいいんじゃないかなあという気も。
max_worker_processes 最大値の変更 8388607から262143になった。 ワーカプロセス数って、もうちょっと上限(略)
old_snapshot_threshold 新規追加 非常に古いスナップショット読み込み挙動のフラグ? きちんと調べて、どういうときにデフォルト(-1)以外之設定が必要か理解しないと・・・
parallel_setup_cost 新規追加 パラレルスキャンのコスト推定パラメータ パラレルスキャンのチューニング時に重要なパラメータになるのか、だいたいの場合デフォルトでいいのかくらいは調べておかないと。
parallel_tuple_cost 新規追加 パラレルスキャンのコスト推定パラメータ パラレルスキャンのチューニング時に重要なパラメータになるのか(略)
replacement_sort_tuples 新規追加 ソート方式(クイックソート/外部ソート)の切り替え閾値(タプル数) 既存のwork_men/maintenance_work_memとの関係も調べるのかな。
server_version 設定値変更 バージョン番号の変更 そういえば10.0beta2になるかも話もあったが・・・
server_version_num 設定値変更 バージョン番号値の変更 そういえば10.0beta2になるかも話もあったが・・・
superuser_reserved_connections 最大値の変更 8388607から262143になった。 max_connectionと同じ話か。
synchronous_commit 値域の追加 remote_applyの追加 WAL反映完了まで待つ、完全な同期レプリケーションが可能になるのかな。
synchronous_standby_names 説明の変更 複数同期スタンバイに対応した説明変更 これも早く自分で動かしてみないとなあ。
syslog_sequence_numbers 新規追加 syslogでメッセージ分割したときの通番付与フラグ? あんまりsyslog出力って使ってないんだよなー。
syslog_split_messages 新規追加 syslogでメッセージ分割するかどうかのフラグ? あんまりsyslog(略)
wal_level 値域の変更 archive,hot_standbyがreplicaに統一された。 過去にPITRやレプリケーション設定方法を書いているドキュメントへの影響がw
wal_writer_delay 説明の変更 説明文の変更のみ。 フラッシュ関係のパラメータ追加とかが関係しているのかな。
wal_writer_flush_after 新規追加 wal_writerの制御パラメータ またフラッシュ関係のパラメータか!

既存の運用に影響があるのは、wal_levelの値域変更、あとは、基本的には新規機能関連かな。
最大値上限が小さくなることで影響を受けるシステムは多分ないと思う・・・。

補足

wal_level については、実は9.5までの設定値であるarchive, hot_standbyを指定しても、きちんと起動する。
また、そのときの設定値は、replica になる。

[nuko@localhost ~]$ grep wal_level /tmp/pg96/postgresql.conf 
#wal_level = minimal			# minimal, replica, or logical
wal_level = archive			# minimal, replica, or logical
#wal_level = hot_standby			# minimal, replica, or logical
[nuko@localhost ~]$ pg_ctl start -D /tmp/pg96/ -l /tmp/pglog
server starting
[nuko@localhost ~]$ psql postgres -c "SELECT name, setting FROM pg_settings WHERE name = 'wal_level'"
   name    | setting 
-----------+---------
 wal_level | replica
(1 row)

[nuko@localhost ~]$ vi /tmp/pg96/postgresql.conf 
[nuko@localhost ~]$ grep wal_level /tmp/pg96/postgresql.conf 
#wal_level = minimal			# minimal, replica, or logical
#wal_level = archive			# minimal, replica, or logical
wal_level = hot_standby			# minimal, replica, or logical
[nuko@localhost ~]$ pg_ctl restart -D /tmp/pg96/ -l /tmp/pglog
waiting for server to shut down.... done
server stopped
server starting
[nuko@localhost ~]$ psql postgres -c "SELECT name, setting FROM pg_settings WHERE name = 'wal_level'"
   name    | setting 
-----------+---------
 wal_level | replica
(1 row)

ただ、ソースコードを見ると、archiveもhot_standbyも設定自体は残っているけど、hidden扱い、かつコメントには deprecated になっているので、9.6にアップデートした契機でなるべく wal_level = replica と記述するようにすべきなんでしょうね。

backend/access/rmgrdesc/xlogdesc.c の抜粋。

const struct config_enum_entry wal_level_options[] = {
        {"minimal", WAL_LEVEL_MINIMAL, false},
        {"replica", WAL_LEVEL_REPLICA, false},
        {"archive", WAL_LEVEL_REPLICA, true},  /* deprecated */
        {"hot_standby", WAL_LEVEL_REPLICA, true},  /* deprecated */
        {"logical", WAL_LEVEL_LOGICAL, false},
        {NULL, 0, false}
};