タイプ: integer
デフォルト: -1 (-1)
分: -1 (-1)
最大: 86400 (60d)
単位: minutes (min)
コンテキスト: postmaster
再起動: true
以来: 9.6

スナップショットを使用する際に、snapshot too oldエラーが起こるリスク無しに問い合わせスナップショットが利用できる最小の期間を設定します。この制限値を越えてデッド状態のままになったデータはバキュームしてしまうことが許可されます。これにより、長い間残っていたスナップショットによりデータが溢れてしまうのを防ぐことができます。スナップショットから見えるデータが消えることによる不正な結果を防ぐため、スナップショットがこの制限値よりも古く、かつこのスナップショットが作られた以降に変更されたページを読むためにスナップショットが使用されるときはエラーが発生します。

この値が単位なしで指定された場合は、分単位であるとみなします。-1(デフォルトです)を設定するとこの機能が無効になり、実質的にスナップショットの寿命を無限にします。このパラメータはサーバ起動時にのみ設定可能です。

実際の環境でのおすすめの値はおそらく数時間から2, 3日の間となるでしょう。小さな値(たとえば01min)は、テストの際に有用だということで許可されています。60dのような大きな値の設定もできますが、多くのワークロードにおいて、大きなデータ溢れやトランザクションIDの周回がそれよりはずっと短い期間で起こる可能性があることに注意してください。

この機能が有効であると、リレーションの終端部にあるフリースペースはオペレーティングシステムには返却されません。そうしないと、snapshot too oldの条件の検出に必要な情報を削除してしまうことになるからです。明示的に解放されない限り(たとえばVACUUM FULLによって)、リレーションに割り当てられた領域は、そのリレーションの中での再利用に限定して紐付けられます。

この設定は、どのような状況でもエラーが検出されることを保証するものではありません。(たとえば)マテリアライズされた結果集合を持つカーソルから正しい結果を得ることができるのであれば、たとえ参照している元のテーブルからVACUUMによって行が削除されたとしてもエラーにはなりません。ある種のテーブルでは、早期にVACUUMできないので、この設定の影響を受けません。例としては、システムカタログが挙げられます。このようなテーブルにおいては、この設定によってデータ溢れを防ぐことも、スキャンの際にsnapshot too oldエラーを起こす可能性を作り出すこともできません。

推奨事項 [EN]

… or the length of the longest transaction you expect to run + 1 hour.

件のコメント