タイプ: | integer |
デフォルト: | 64 |
分: | 10 |
最大: | 2147483647 |
コンテキスト: | postmaster |
再起動: | true |
共有ロックテーブルは、max_locks_per_transaction
* (max_connections + max_prepared_transactions)オブジェクト(例えばテーブル)上のロック追跡します。したがって、ある時点でこの数以上の個々のオブジェクトをロックすることはできません。このパラメータは各トランザクションで割り当てられるオブジェクトロックの平均値を制御します。個々のトランザクションでは、このロックテーブルにすべてのトランザクションのロックが収まる限りオブジェクトのロックを獲得できます。これは、ロックできる行数ではありません。この値には制限がありません。デフォルトの64は、経験的に十分であると証明されていますが、単一のトランザクションで数多くの異なるテーブルをいじる問い合わせがいる場合、たとえば、数多くの子テーブルを持つ親テーブルの問い合わせなど、この値を大きくする必要があるかも知れません。このパラメータはサーバ起動時のみ設定されます。
スタンバイサーバを稼動するとき、このパラメータをマスターサーバと同じか、より高い値に設定しなければなりません。 そうしないと、問い合わせはスタンバイサーバでは許可されません。
推奨事項 [EN]
Some databases with very complex schema or with many long-running tranactions need a higher amount. This is rare though.
On StackOverflow
On pgsql-hackers
- Re: allow changing autovacuum_max_workers without restarting
- Re: Fix the description of GUC "max_locks_per_transaction" and "max_pred_locks_per_transaction" in guc_table.c
- Re: scalability bottlenecks with (many) partitions (and more)
- Re: partitioning and identity column
- Re: pg_upgrade failing for 200+ million Large Objects