max_pred_locks_per_transaction

Definition PG 18 manual

The shared predicate lock table has space for max_pred_locks_per_transaction objects (e.g., tables) per server process or prepared transaction; hence, no more than this many distinct objects can be locked at any one time. This parameter limits the average number of object locks used by each transaction; individual transactions can lock more objects as long as the locks of all transactions fit in the lock table. This is not the number of rows that can be locked; that value is unlimited. The default, 64, has historically proven sufficient, but you might need to raise this value if you have clients that touch many different tables in a single serializable transaction. This parameter can only be set at server start.

How it works

Sets the maximum number of predicate locks per transaction. The value is fixed when the server starts, so changing it requires a restart.

This sizes the shared predicate-lock table per backend or prepared transaction for SERIALIZABLE conflict tracking. It is an average shared-memory allocation rather than a hard per-transaction ceiling, and is unrelated to ordinary row-lock counts.

Monitor and change max_pred_locks_per_transaction together with deadlock_timeout, log_lock_waits, lock_timeout. Validate on the relevant server role and real workload, then use its postmaster context to choose session change, reload, or restart; a historical boot default is not the current effective value.

Operational considerations

Reading an average shared-memory sizing value as a hard per-transaction limit.

Raising it without the multiplier from connections and prepared transactions.

Expanding lock memory instead of fixing long transactions, access order, or partition explosion.

Ignoring compatible startup lock capacity on standbys.

Workload guidance

OLAP: Partitioned queries, bulk DDL, and SERIALIZABLE reports may touch many objects; test the worst plan, not only an average transaction.

OLTP: Calibrate max_pred_locks_per_transaction from lock-wait logs, objects touched, and the concurrency bound. Fix long transactions and access ordering before adding shared memory or changing detection granularity.

SMALL: Defaults are usually sufficient. If raising a startup lock-table setting, account for max_connections, prepared transactions, and standby consistency together.