Re: Comment on max_locks_per_transaction
От | Bruce Momjian |
---|---|
Тема | Re: Comment on max_locks_per_transaction |
Дата | |
Msg-id | 20120830205638.GA8753@momjian.us обсуждение исходный текст |
Ответ на | Comment on max_locks_per_transaction (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-docs |
I have applied the attached patch to document this issue. --------------------------------------------------------------------------- On Fri, Jun 15, 2012 at 11:05:30AM -0700, Josh Berkus wrote: > 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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-docs -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
Вложения
В списке pgsql-docs по дате отправления: