[pgsql-jp: 40386] Re: max_locks_per_transactionとpg_dumpの関係

[Itagaki Takahiro]

2010/9/10 川原泰三 <t_kawahara-osk ＠ sdcns.co.jp>:
> ERROR: out of shared memory
> HINT:  You may need to increase max_locks_per_transaction.
>
> 調査は max_locks_per_transaction を増加させ pg_dump が可能な
> 限界値を測定することで、関係式は無理やり作りましたが、その
> 理由がわからないため納得できておりません。

非常にたくさんのテーブルやインデックスを含むデータベースを
ダンプされているのではないでしょうか？  PostgreSQLには、
行ロックの数には上限は無いものの、テーブルロックの数には
max_locks_per_transaction に依存する上限があります。
エラーは、この上限にひっかかったことを示しています。

ドキュメントにもあるように、
  http://www.postgresql.jp/document/current/html/runtime-config-locks.html
max_locks_per_transaction の値そのものとうよりは、
  max_locks_per_transaction * (max_connections + max_prepared_transactions)
の値が影響します。これが、インスタンス全体で可能な
テーブルロック数の上限になります。

普通のトランザクションでは一度にはそんなにたくさんのテーブルに
触ることは少ないでしょうから、例えば 30 くらいと仮定すると、

 (上記の値) > (テーブルとインデックスの総数) + 30 * (実際の接続数)

ほどになるような設定が必要です。
デフォルトの max_locks_per_transaction は 64 ですから、
pg_dump のような大量のロックが必要な処理があっても、大概は
他のトランザクションが使っていないぶんで賄えることが多いのですが、
スキーマ構成によっては足りなくなる場合もあるということでしょうね。

その他細かいことですが：
・あるテーブルを触る場合、その上のインデックスもすべてロックされます。
・上で「テーブルロック」とは言っていますが、単にDROPを禁止するだけで
　参照も更新も並行して走れます。

-- 
Itagaki Takahiro