Skip site navigation (1) Skip section navigation (2)

Re: Comment on max_locks_per_transaction

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-docs(at)postgreSQL(dot)org
Subject: Re: Comment on max_locks_per_transaction
Date: 2012-08-30 20:56:38
Message-ID: 20120830205638.GA8753@momjian.us (view raw or flat)
Thread:
Lists: 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(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. +

Attachment: locks.diff
Description: text/x-diff (1.1 KB)

In response to

pgsql-docs by date

Next:From: Bruce MomjianDate: 2012-08-30 21:58:48
Subject: Re: Out of date advice about SIGTERM'ing backends
Previous:From: Bruce MomjianDate: 2012-08-30 18:45:39
Subject: Re: vacuum monitoring in the doc

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group