 | |
[DOCS] Comment on max_locks_per_transaction
mailing.database.pgsql-docs mailing.database.pgsql-docs
 |
| | Thread Tools | Display Modes |
#11
 
| |||
| |||
|
Re: [DOCS] Comment on max_locks_per_transaction -
08-30-2012
, 03:56 PM
|
Folks, Way it is now: =============== max_locks_per_transaction (integer) The shared lock table tracks locks on max_locks_per_transaction * (max_connections + max_prepared_transactions) objects (e.g., tables); hence, no more than this many distinct objects can be locked at any one time. This parameter controls the average number of object locks allocated for 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 transaction. This parameter can only be set at server start. Increasing this parameter might cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary. When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server. ================ The way it should be: max_locks_per_transaction (integer) The shared lock table tracks locks on max_locks_per_transaction * (max_connections + max_prepared_transactions) objects (e.g., tables); hence, no more than this many distinct objects can be locked at any one time. This parameter controls the average number of object locks allocated for 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. This parameter can only be set at server start. The default, 64, has historically proven sufficient for most databases, but you might need to raise this value if you have clients that touch many different tables in a single transaction. Databases with several tables with many partitions each can require raising this setting. The PostgreSQL activity log will contain a fairly clear error message suggesting raising max_locks_per_transaction if needed. Increasing this parameter might cause PostgreSQL to request more System V shared memory than your operating system's default configuration allows. See Section 17.4.1 for information on how to adjust those parameters, if necessary. When running a standby server, you must set this parameter to the same or higher value than on the master server. Otherwise, queries will not be allowed in the standby server. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-docs mailing list (pgsql-docs (AT) postgresql (DOT) org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-docs |
Bruce Momjian <bruce (AT) momjian (DOT) us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-docs mailing list (pgsql-docs (AT) postgresql (DOT) org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2013, Jelsoft Enterprises Ltd.