Database postragesql lock management

19.12. Lock management

deadlock_timeout (integer)

This is the total time spent waiting on a lock before deadlock detection （ In milliseconds ）. Deadlock detection is relatively expensive , So the server doesn't run this every time it waits for a lock . We optimistically assume that deadlocks are uncommon in production applications , And only wait for a while before starting to detect deadlocks . Increasing this value reduces the time wasted on useless deadlock detection , But it slows down the reporting of real deadlock errors . The default is 1 second （1s）, This may be the minimum you want in practice . On a high load server , You may need to increase it . The ideal setting for this value should be longer than your usual transaction time , This reduces the chance to start deadlock checking before the lock is released . Only super users can change this setting .

When ​​log_lock_waits​​​ When set , This parameter can also determine the length of time to wait before issuing a log on lock wait . If you want to investigate lock delay , You may want to set a more normal ​​deadlock_timeout​​ Small value .

max_locks_per_transaction (integer)

Shared lock table tracking in ​​max_locks_per_transaction * (max_connections + max_prepared_transactions)​​ Objects （ As shown in the table ） The lock on the . therefore , At any moment , Only so many distinguishable objects can be locked . This parameter controls the average number of object locks allocated to each transaction . Individual transactions can lock more objects , The number of locks can be as many as all transactions in the lock table can hold . This is not the number of lines that can be locked , There is no limit to that value . The default value is 64 It has been proved by history that it is enough , But if

You need to use queries from many different tables in a transaction （ For example, query a parent table with many child tables ）, You may need to increase this value . This parameter can only be set when the server is started .

When running a backup server , You must set this parameter to be greater than or equal to the value on the primary server . otherwise , Queries will not be allowed on the backup server .

max_pred_locks_per_transaction (integer)

Shared predicate lock table tracking in ​​max_pred_locks_per_transaction * (max_connections +max_prepared_transactions)​​ Objects （ As shown in the table ） The lock on the . therefore , At any moment , Only so many distinguishable objects can be locked . This parameter controls the average number of object locks allocated to each transaction . Individual transactions can lock more objects , The number of locks can be as many as all transactions in the lock table can hold . This is not the number of lines that can be locked , There is no limit to that value . The default value is 64 It has been shown in tests that it is usually sufficient , But if you need to use queries from many different tables in a serializable transaction （ For example, query a parent table with many child tables ）, You may need to increase this value . This parameter can only be set when the server is started .

max_pred_locks_per_relation (integer)

This parameter controls before predicate locks are promoted to cover the entire relationship , How many pages or tuples can this predicate lock on a single relationship . A value greater than or equal to zero represents an absolute limit , Negative values indicate that ​​max_pred_locks_per_transaction​​ Divided by the absolute value of this setting . The default value is -2, It will keep the previous version of PostgreSQL Behavior in . This parameter can only be in ​​postgresql.conf​​ File or on the server command line .

max_pred_locks_per_page (integer)

This parameter controls until the predicate lock is promoted to cover the entire page , How many rows can this predicate lock lock on a single page . The default value is 2. This parameter can only be in ​​postgresql.conf​​ File or on the server command line .